Ultieme Comprimering op CD-ROM..?

[StalieN]

Hoi Mensen,

Misschien hebben jullie allemaal wel gehoord dat er een man was die bij Philips een contractje had getekent waarmee hij rijker dan Gates zou worden (nee... geen sprookje). Hij had namelijk een keisimpele techniek bedacht om op een CD-ROM zoveel data te frotten dat op een disc alle films van de wereld zouden passen (DVD kwalitie...). Hij had dit nergens opgeschreven, gewoon in z'n hoofd zitten. Op de dag van bekendmaking (patenten en al waren geregeld) overleed hij aan een hartaanval en niemand heeft kunnen vinden wat zijn idee nou was. Klinkt raar en ongelooflijk maar waargebeurd (Philips top-man Boonstra: ''Jammer, maar er zal nog wel eens iemand met hetzelfde idee komen'').

Dit zette mij aan het denken. Als het antwoord voor de hand ligt, moeten we alleen de draadjes aan elkaar binden. En aangezien ik niet alles weet van die techniek... komen we er misschien met z'n allen uit?
----------
Ik begin met een idee dat ik had:

Op een CD-ROM staat 700Mb = 700 * 1024 *1024 bytes = ca. 7,34 * 10^8 bytes

(7,34 * 10^8) * 8 bits = 5,87 * 10^9 bits op een disc (5,8 miljard).

Het idee van het binaire stelsel is hopelijk duidelijk: 1 en 0, 8 bits = 2^8 = 256 verschillende tekens.
Als je nu 9 bits neemt, 2^9 = 512 verschillende tekens -> twee keer zoveel tekens maar slechts 1/8 deel van de CD-Rom in geleverd! Dat is dus een vette winst.

Ok, als we nu alle bits in één tekenset stoppen, dan krijgen we:
2^5,872025600 verschillende tekens = veel: probeer maar eens uit te rekenen...

dit getal delen door 256 delen door 1024 delen door 1024 is heeel veel mb's aan schijfruimte....

ik weet dat het probleem zit in de processors die op het moment nog lang niet snel genoeg zijn om zo'n groot getal de lezen en te comprimeren en te begrijpen (heb je veeel geheugen voor nodig denk ik...) maar kan iemand het getal uitrekenen of er iets tegeninbrengen? klopt er misschien iets niet?
misschien heeft iemand anders nog andere ideeën..?
ik hoor het wel

groetjes

[xentric]

Ja ik heb daar toen ook van gehoord. Eeuwig zonde dat zo'n kerel net moest bezwijken aan een hartaanval terwijl Philips juist met zijn plannen aan de slag wilde gaan.

Heb je toevallig een link naar eventueel iets meer info over wat de beste man in elkaar had geknutseld !?

[PipoDeClown]

quote:

Ok, als we nu alle bits in één tekenset stoppen, dan krijgen we:
2^5,872025600 verschillende tekens = veel: probeer maar eens uit te rekenen...

dit getal delen door 256 delen door 1024 delen door 1024 is heeel veel mb's aan schijfruimte....

Nice try

[Captain Proton]

quote:

Misschien hebben jullie allemaal wel gehoord dat er een man was die bij Philips een contractje had getekent waarmee hij rijker dan Gates zou worden (nee... geen sprookje). Hij had namelijk een keisimpele techniek bedacht om op een CD-ROM zoveel data te frotten dat op een disc alle films van de wereld zouden passen (DVD kwalitie...). Hij had dit nergens opgeschreven, gewoon in z'n hoofd zitten. Op de dag van bekendmaking (patenten en al waren geregeld) overleed hij aan een hartaanval en niemand heeft kunnen vinden wat zijn idee nou was. Klinkt raar en ongelooflijk maar waargebeurd (Philips top-man Boonstra: ''Jammer, maar er zal nog wel eens iemand met hetzelfde idee komen'').

Dit zette mij aan het denken. Als het antwoord voor de hand ligt, moeten we alleen de draadjes aan elkaar binden. En aangezien ik niet alles weet van die techniek... komen we er misschien met z'n allen uit?

Dit is idd al eens langsgekomen, we hebben toen geconcludeerd dat het een broodje aap was. Er is een grens aan de hoeveelheid compressie die je kan toepassen zonder informatie te verliezen, hoe meer compressie je toepast, hoe meer "random" de resterende bits worden. Op een gegeven moment is de data bijna volledig "random" en heeft verdere compressie dus geen zin meer. Net zoiets als de perpetuum mobile: Wat je ook probeert, de winst die je denkt te hebben, valt uiteindelijk vies tegen

quote:

Ik begin met een idee dat ik had:

Op een CD-ROM staat 700Mb = 700 * 1024 *1024 bytes = ca. 7,34 * 10^8 bytes

(7,34 * 10^8) * 8 bits = 5,87 * 10^9 bits op een disc (5,8 miljard).

Het idee van het binaire stelsel is hopelijk duidelijk: 1 en 0, 8 bits = 2^8 = 256 verschillende tekens.
Als je nu 9 bits neemt, 2^9 = 512 verschillende tekens -> twee keer zoveel tekens maar slechts 1/8 deel van de CD-Rom in geleverd! Dat is dus een vette winst.

Zeker, maar daar heb je weinig aan aangezien je geen tekens hebt om dit mee te vullen...

quote:

Ok, als we nu alle bits in één tekenset stoppen, dan krijgen we:
2^5872025600 verschillende tekens = veel: probeer maar eens uit te rekenen...

Zeker veel. Echter, je moet nu wel voor elke combinatie van 700MB aan 8-bit tekens een positie binnen die 2^5872025600 tekens reserveren. Raad eens hoeveel bits je daarvoor nodig hebt? Juist: exact 2^5872025600

In andere woorden, je slaat nu niet de data op, maar de positie waar een referentiechip de complete data-stream kan vinden. Erg omslachtig, en het levert bovendien een compressie van 0% op. Daar heb je dus helemaal niets aan. Bovendien heb je gelijk dat geen enkele processor dit aan kan...

[xentric]

quote:

Op vrijdag 31 mei 2002 20:40 schreef Captain Proton het volgende:
Dit is idd al eens langsgekomen, we hebben toen geconcludeerd dat het een broodje aap was. Er is een grens aan de hoeveelheid compressie die je kan toepassen zonder informatie te verliezen, hoe meer compressie je toepast, hoe meer "random" de resterende bits worden.

Het kan wel als meneer een efficiente manier had uitgevonden om een soort fractal-compressie toe te passen. Zoiets in de trant van, je zet data om naar een 'formule' die dezelfde data als output geeft. Dit krijg je absoluut nooit netjes voor graphics, maar audio kan best lukken als je een retesnelle computer hebt en een goed algorithme om de data om te zetten naar 'formules'...

Maar lossless compressie op dit niveau is inderdaad echt onmogelijk!

[Captain Proton]

quote:

Het kan wel als meneer een efficiente manier had uitgevonden om een soort fractal- compressie toe te passen. Zoiets in de trant van, je zet data om naar een 'formule' die dezelfde data als output geeft. Dit krijg je absoluut nooit netjes voor graphics, maar audio kan best lukken als je een retesnelle computer hebt en een goed algorithme om de data om te zetten naar 'formules'...

Dat hangt ervanaf welke kwaliteit je wilt halen met je compressie. Als je werkelijk lossless wilt comprimeren, heeft zelfs een fractale compressie geen zin aangezien dan de parameters die je op moet geven om de data uit de formule te krijgen, evenveel ruimte innemen als de data. Geloof mij, je wordt altijd ERGENS teruggepakt

Echter, als je genoegen neemt met iets mindere kwaliteit, kan dit een interessante compressiemethode zijn omdat de grootte van de parameters dan snel afneemt.

[Slashdotter]

Khep het verhaal eens gecheckt bij iemand van Philips (afdeling patent registratie) en hij bevestigde het broodje aap status.

Helaas pindakaas

[Juggalin_Juggalo]

Oooh, kom op, niet weer die lulkoek van die Philips gast met z'n films in 16Kb Prachtverhaal hoor, maar oh wat een gelul.

Luister, het is onmogelijk een compressie te bedenken die data altijd kleiner maakt.

Op een cd staan 5,9 miljard bits. In die bits kun je 2^{5,9 miljard} mogelijke stukken data opslaan van 700Mb. En je kunt op je kop gaan staan, de bits in het chinees opschrijven, de cd een uur in de magnetron leggen of je hond erop laten schijten, je krijgt er geen één mogelijkheid extra door.

[TheRademaker]

Ik heb dat inderdaad op het news gezien.

Een Amerikaans bedrijf(ik geloof Panasonic) bood de man 250 Miljard Dollar voor zijn uitvinding.

Ik denk dat de man alleen al door dit aanbod een hartaanval kreeg.

Ik vind het erg jammer dat deze man is overleden,.....hij had de technologie sector totaal op zijn kop kunnen zetten en voor altijd de wereld hebben kunnen veranderd.

Als zoveel data op zo'n schijfje past.....dan zal dat een enorme impact hebben op de toekomst vd mens.

[Beelzebubu]

Ik heb zelf altijd geloofd dat het verhaal zoals het in de kranten verteld is dikke onzin is, maar dat de man waarschijnlijk werkte aan de opvolger van de DVD, dus iets ter (geometrische) grootte van een CD waar dan heel veel meer data op paste (digitale grootte).

Zoals we weten willen media dit soort verhalen graag uit zijn verband rukken en gaan blaten over 16kB films enzo. En dat kan niet. .

[TheRademaker]

Is er een site waar ik alle patenten kan bekijken die zijn aangevraagd door bedrijven in de wereld?

[StalieN]

quote:

Heb je toevallig een link naar eventueel iets meer info over wat de beste man in elkaar had geknutseld !?

Jep... kheb iets gevonden, Tweakers heeft er ooit een nieuwsbericht aan besteedt: http://www.tweakers.net/nieuws/15456

quote:

Nice try

Slaap lekker...

quote:

Er is een grens aan de hoeveelheid compressie die je kan toepassen zonder informatie te verliezen, hoe meer compressie je toepast, hoe meer "random" de resterende bits worden. Op een gegeven moment is de data bijna volledig "random" en heeft verdere compressie dus geen zin meer. Net zoiets als de perpetuum mobile: Wat je ook probeert, de winst die je denkt te hebben, valt uiteindelijk vies tegen

Maar dit is geen dataloss, het kost alleen processorkracht... toch?

[StalieN]

quote:

Zeker veel. Echter, je moet nu wel voor elke combinatie van 700MB aan 8-bit tekens een positie binnen die 2^5872025600 tekens reserveren. Raad eens hoeveel bits je daarvoor nodig hebt? Juist: exact 2^5872025600
In andere woorden, je slaat nu niet de data op, maar de positie waar een referentiechip de complete data-stream kan vinden. Erg omslachtig, en het levert bovendien een compressie van 0% op. Daar heb je dus helemaal niets aan.

Maar als je in de cd-rom speler een chip aan zou brengen die de juiste positionering weet, dan heb je toch een gigantische compressie? zonder dataloss... het enige probleem is de processorkracht.. toch?

quote:

Als je werkelijk lossless wilt comprimeren, heeft zelfs een fractale compressie geen zin aangezien dan de parameters die je op moet geven om de data uit de formule te krijgen, evenveel ruimte innemen als de data. Geloof mij, je wordt altijd ERGENS teruggepakt

Maar een 9bits tekenset heeft toch ook geen dataloss? je hebt gewoon 512 verschillende tekens, dat is toch geen dataloss?

quote:

Luister, het is onmogelijk een compressie te bedenken die data altijd kleiner maakt

Hoezo? De 9bits compressie is de eerste-altijd compressie die je tegenkomt!

[StalieN]

quote:

Is er een site waar ik alle patenten kan bekijken die zijn aangevraagd door bedrijven in de wereld?

Geen idee....


Ik denk nog steeds dat het zeker niet onmogelijk is. Het schijnt dat die man gezegd heeft dat het zo'n simpele techniektoepassing was dat iedereen die een beetje van de CD-ROM techniek afwist, het kon bedenken. Al is het verhaal van die man maar half waar, er moet toch iets zijn waarmee een groot aantal data op een CD beschreven kan worden. Met de DVD is men al een stap verder gekomen. Aan Havard Universiteit is een Femtolaser ontwikkeld: een laser die in glasplaat kan branden op gigantische precizie en snelheid én diepte: je kan bijvoorbeeld putjes van één nanometer diep maar ook van twee of een half enz. hierdoor kan in 3D worden opgeslagen (http://mazur-www.harvard.edu/). Dan is er ook nog een onderzoek naar CDbranden in verschillende kleuren -> de reflectie verschilt in golflengte en die zijn dan weer te onderscheiden waardoor veel meer informatie opgeslagen kan worden. Als al deze technieken met elkaar verbonden zouden worden, én er wordt een ultieme manier voor dataloss comprimeren gevonden dan maakt de techniek een grote stap vooruit!

PS: moest in 3 berichtjes: anders wasset te lang...

[xentric]

quote:

Op zaterdag 01 juni 2002 19:31 schreef StalieN het volgende:

[..]

Maar als je in de cd-rom speler een chip aan zou brengen die de juiste positionering weet, dan heb je toch een gigantische compressie? zonder dataloss... het enige probleem is de processorkracht.. toch?
[..]

Maar een 9bits tekenset heeft toch ook geen dataloss? je hebt gewoon 512 verschillende tekens, dat is toch geen dataloss?
[..]

Hoezo? De 9bits compressie is de eerste-altijd compressie die je tegenkomt!

Als je nou eens een stuk papier pakt en een paar simpele stappen van jouw 9-bits techniek doorrekend, en vervolgens terug gaat rekenen naar de originele data dan zal je zien dat je nergens komt. Ik snap je hele 9-bits idee trouwens nog niet helemaal... Wat wil je nu met zo veel tekens. Wat heeft dat voor nut?

Als je kijkt naar bijvoorbeeld zip-compressie dan werkt dat gewoon met een soort library van veel voorkomende stukken data in de te comprimeren file. Er wordt voor die stukken code een zo kort mogelijke vervangende code gegeven. En wat een van de vorige posters bedoelde is dat je met zo'n compressie na een paar rondjes al zoveel random data hebt dat er geen optimalisatie meer uit het gebruik van een library, met veel voorkomende data, te halen is. Snappie !?

Morse-code is bijvoorbeeld op hetzelfde principe gebaseerd. Als je een letter-frequency-tabel naast een tabel met de morsecodes legt dan zie je waarom bijvoorbeeld [e=.] [i=..] [t=_] de meest voorkomende tekens, zo kort mogelijk zijn om het verzenden te optimaliseren. Bitwise gezien pas je dus compressie toe want een [e] is maar 1 bit in plaats van 4 bits en omdat de [e] het vaakst voorkomt in teksten is de compressie van die letter dus optimaal.

Voorbeeldje:

Als we de string [abcdefg] omzetten met een 5 bits tekenset (genoeg voor lowercaps alfabet) dan krijgen we:
[00001|00010|00011|00100|00101|00110|00111] en dat zijn dus 35 bits. Als we vervolgens de morse techniek toepassen met een vaste tijdseenheid tussen letters dan krijgen we:
[.-|-...|-.-.|-..|.|..-.|--.] en dat zijn inprincipe 21 bits als we de reeks zouden schrijven als [01|1000|1010|100|0|0010|110]

Hier heb je dus een lossless compressie toegepast als je ervanuitgaat dat de hardware rekening houd met een vaste pauze tussen de bits van iedere letter om een volgende letter te kunnen onderscheiden. Dus door van pauzering technieken gebruik te maken kunnen we extra comprimeren omdat een letter zelfs 1 bit groot mag zijn.

(even voor de duidelijkheid, ik heb het hier over compressie voordat de data de lijn op gaat, dus een transmissie-compressie)

Maar de bovenstaande string voldoet niet helemaal aan de vaste library die voor morse geldt. Als je betere compressie van deze string wilt hebben dan zou je een nieuwe indeling moeten maken adhv de te comprimeren data. Dit is wat zip-compressie dus ook doet. Het probleem bij zo'n kleine string is dus dat je die nieuwe library moet toevoegen om te kunnen decoderen, en dan is het denk ik zelfs groter dan ongecodeerd. Dus het blijft schipperen met wat nou optimaal is.

Nou, probeer maar eens wat op papier, of probeer een simpele programmeertaal zoals turbo-pascal te leren waarmee je makkelijk en zeer snel al je ideeen kan testen. Je zal zien, comprimeren is moeilijker dan het lijkt!

[BadRespawn630]

quote:

Op zaterdag 01 juni 2002 20:32 schreef xentric het volgende:
Als we vervolgens de morse techniek toepassen met een vaste tijdseenheid tussen letters dan krijgen we:
[.-|-...|-.-.|-..|.|..-.|--.] en dat zijn inprincipe 21 bits als we de reeks zouden schrijven als [01|1000|1010|100|0|0010|110]

Je vergeet de vaste tijdseenheid tussen de letters; om die binair weer te geven heb je waarschijnlijk meer dan 1 bit nodig omdat je 'byte'/word-lengte variabel is. hoe weet je anders bij het lezen waar een letter begint?

[xentric]

quote:

Op zaterdag 01 juni 2002 21:01 schreef BadRespawn het volgende:
Je vergeet de vaste tijdseenheid tussen de letters

Heb je een brilletje nodig ofzo !? Lees eens wat er in de volgende alinea staat...

[Edit]
Even een kleine aanpassing gedaan in italics zodat het nog duidelijker is.

[StalieN]

Ok xentric, ik snap je verhaal, maar dat is toch een hele andere manier van comprimeren?
Ik kan het nu niet uitgebreidt maken maar ik zal een rekensommetje met de 9bits uitwerken en hier neerfrotten a.s. maandag.
Morgen ben ik de hele dag weg dus houdt de topic actief dattie maandag nog bestaat
dan leg ik het even uit...

[Keida]

Volgens mij kun je pas echt goed comprimeren, als je op de één of andere manier zo kunt regelen dat zeg maar: teken 1 zegt wat over teken 2, teken 1+2 zegt wat over teken 3, maar teken 3 is op zich ook voldoende voor teken 3 zelf. Teken 3+4 of het verschil daartussen zegt weer wat over teken 5...

Of dat teken 1+2 direct teken 3 maakt of zo...

eeh, dus.. Nou ja, mij idee dan heh?

Dus dan heb je minder tekens nodig, omdat een teken meer dan 1 ding betekent...

[xentric]

quote:

Op zaterdag 01 juni 2002 23:34 schreef Redkef het volgende:
Volgens mij kun je pas echt goed comprimeren, als je op de één of andere manier zo kunt regelen dat zeg maar: teken 1 zegt wat over teken 2, teken 1+2 zegt wat over teken 3, maar teken 3 is op zich ook voldoende voor teken 3 zelf. Teken 3+4 of het verschil daartussen zegt weer wat over teken 5...

Of dat teken 1+2 direct teken 3 maakt of zo...

eeh, dus.. Nou ja, mij idee dan heh?

Dus dan heb je minder tekens nodig, omdat een teken meer dan 1 ding betekent...

Lol, probeer jij jouw methode ook maar eens uit op papier
Ik kan met enige zekerheid voorspellen dat je geen werkend voorbeeld kan verzinnen. Ik heb dit namelijk ook wel eens geprobeerd, maar na een paar pogingen zie je meteen waar het probleem ligt... Probeer het maar eens!

[abveldeh619]

Las eergister dat met nieuwe techniek(laser binnen golflengte van schijf) in drie jaar een terrabite per schijfje mogelijk is, dus het zal op den duur wel lukken

[Juggalin_Juggalo]

quote:

Hoezo? De 9bits compressie is de eerste-altijd compressie die je tegenkomt!

Nee. Kijk, jij zegt: "Als je nu 9 bits neemt, 2^9 = 512 verschillende tekens -> twee keer zoveel tekens maar slechts 1/8 deel van de CD-Rom in geleverd! Dat is dus een vette winst."

Dus je krijgt dan als het ware "bytes" van 9 bits, dus elk "teken" heeft 512 mogelijkheden ipv 256. Voor deze verdubbeling aan mogelijkheden wordt elke byte "slechts" 1/8 groter. Dat is maar schijn, je schiet er geen reet mee op. Die verdubbeling kost je een bit, en dat is logisch, want een bit heeft 2 mogelijkheden. Dus het aantal mogelijkheden met dat bit erbij, is dan ook 2 maal het aantal mogelijkheden wat je eerst had (zonder dat extra bit per 'teken').

Als je het niet wilt geloven: laten we eens kijken hoeveel mogelijkheden we in 9 "oude" bytes (of tekens) kunnen opslaan. Die hebben dus gewoon 8 bits per stuk, dus in totaal zijn dat 72 bits. Aantal mogelijkheden is dus 2⁷². Door deze zelfde ruimte op de CD als "nieuwe" bytes (dus van 9 bits per stuk) te gebruiken, passen er slechts 8 in (geen 9), maar wel elk met twee keer zoveel mogelijkheden. Welaan, het aantal mogelijkheden wat we in die 8 "nieuwe" tekens (van 9 bits elk) kunnen opslaan, is... uiteraard nog steeds 2⁷².

Je moet niet in tekens of bytes denken van 8, 9 of weet ik hoeveel miljoen bits. Want daarmee verander je niets aan het feit dat er op een CD 5,9 miljard bits staan.

Ik word ook nogal moe van elke keer weer die trieste berichten van een bedrijf wat meent de ultieme compressie te hebben gevonden waarmee ze alles kunnen verkleinen. Dat kan niet! Je kunt GEEN compressie verzinnen waarmee je elke data kunt comprimeren tot iets kleiners, ook al is het slechts een verkleining van 1 bit. Ik moet helemaal hard lachen om die sukkels van investeerders die dan nog met dat soort lui in zee gaan ook. Maar goed.

StalieN, begrijp je waarom het niet kan? Dat een bepaalde hoeveelheid bits nou eenmaal een vast aantal mogelijkheden heeft, en dat je daar dan niet meer mogelijkheden in kunt proppen?

[js962]

quote:

Op vrijdag 31 mei 2002 20:36 schreef xentric het volgende:
Ja ik heb daar toen ook van gehoord. Eeuwig zonde dat zo'n kerel net moest bezwijken aan een hartaanval terwijl Philips juist met zijn plannen aan de slag wilde gaan.

Heb je toevallig een link naar eventueel iets meer info over wat de beste man in elkaar had geknutseld !?

Hier is wat meer info te vinden
http://www.gids.nl/techno/jan-sloot.html


Het Sloot Digital Coding System (soes) zou de wereld opschudden: een nieuw alfabet voor digitale informatieopslag dat niet langer meer gebruikmaakt van het binaire stelsel van nulletjes en eentjes, maar een veel efficientere methode hanteert. Het principe werkte ogenschijnlijk simpel. Net zoals er voor een stuk tekst maar een beperkt aantal karakters beschikbaar is, wordt een film uit een eindig aantal kleuren en geluiden opgebouwd. Al die basisgegevens werden in vijf algoritmes in vijf verschillende geheugens opgeslagen. Bij de opslag van films zou ieder algoritme een maximale omvang van 74 megabyte krijgen. In totaal dus 370 megabyte: de motor van de vinding. Het enige wat nodig was om die te starten was een passende sleutel. Sloot berekende voor iedere bladzijde van een boek, of ieder beeld van een film, een unieke code waarvan het geheel ook weer resulteerde in een unieke code. Die laatste code, de sleutel, nam slechts één kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek. Op één simpele chipkaart konden op die manier tientallen sleutels worden opgeslagen. Iemand zou bijvoorbeeld, tegen betaling, met een gsm binnen enkele seconden de sleutels van een aantal films kunnen verkrijgen om die thuis via een afspeler met de basisalgoritmes te bekijken. Een technologie kortom, met een onvoorstelbaar potentieel voor creatieve destructie. Alle geluidsdragende industrieen - cd, dvd, tape, diskette - zouden niet lang meer bestaan. Bedrijven die miljarden investeren in glasvezelnetwerken evenmin. Het aloude koperdraadje zou plotseling weer goud waard zijn. Hetzelfde geldt voor gsm. En wat te denken van alle denkbare vormen van consumentenelektronica die beeld en geluid of andere informatie voortbrengen? Niets zou hetzelfde blijven. Het bedrijf met de licenties op SDCS zou, zo stelde Roei Pieper handenwrijvend vast, honderden miljarden dollars waard zijn.

[croxz]

quote:

Op zaterdag 01 juni 2002 23:04 schreef StalieN het volgende:
Ok xentric, ik snap je verhaal, maar dat is toch een hele andere manier van comprimeren?
Ik kan het nu niet uitgebreidt maken maar ik zal een rekensommetje met de 9bits uitwerken en hier neerfrotten a.s. maandag.
Morgen ben ik de hele dag weg dus houdt de topic actief dattie maandag nog bestaat
dan leg ik het even uit...

Het onderverdelen van een datareeks in bits, bytes, hexadecimaal, etc. is alleen om het ons makkelijker te maken er mee te werken, het verandert niets aan de hoeveelheid informatie.
Neem bijvoorbeeld 72 bits, die kan je onderverdelen in 9 bytes of 8 nites (=9 bit, wis hier geen geldig woord voor):

9 x byte (=256 unieke mogelijkheden)
8 x nite (=512 unieke mogelijkheden)

Jouw beredenering is dat het eerste 9 x 256 = 2304 unieke mogelijkheden geeft en het tweede 8 x 512 = 4096. Wat je vergeet dat een getallenstelsel met machtsverheffen werkt, niet vermenigvuldigen. Zo geven 2 bytes al 256^2= 65536 unieke mogelijkheden. De juiste berekening is dan ook:
256^9 = 4.7 x 10^21
512^8 = 4.7 x 10^21
Ze zijn gelijk.

[Wouter Tinus]

quote:

Op zondag 02 juni 2002 00:11 schreef js962 het volgende:
Hier is wat meer info te vinden
http://www.gids.nl/techno/jan-sloot.html

Het Sloot Digital Coding System (soes) zou de wereld opschudden: een nieuw alfabet voor digitale informatieopslag dat niet langer meer gebruikmaakt van het binaire stelsel van nulletjes en eentjes, maar een veel efficientere methode hanteert. Het principe werkte ogenschijnlijk simpel. Net zoals er voor een stuk tekst maar een beperkt aantal karakters beschikbaar is, wordt een film uit een eindig aantal kleuren en geluiden opgebouwd. Al die basisgegevens werden in vijf algoritmes in vijf verschillende geheugens opgeslagen. Bij de opslag van films zou ieder algoritme een maximale omvang van 74 megabyte krijgen. In totaal dus 370 megabyte: de motor van de vinding. Het enige wat nodig was om die te starten was een passende sleutel. Sloot berekende voor iedere bladzijde van een boek, of ieder beeld van een film, een unieke code waarvan het geheel ook weer resulteerde in een unieke code. Die laatste code, de sleutel, nam slechts één kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek. Op één simpele chipkaart konden op die manier tientallen sleutels worden opgeslagen. Iemand zou bijvoorbeeld, tegen betaling, met een gsm binnen enkele seconden de sleutels van een aantal films kunnen verkrijgen om die thuis via een afspeler met de basisalgoritmes te bekijken. Een technologie kortom, met een onvoorstelbaar potentieel voor creatieve destructie. Alle geluidsdragende industrieen - cd, dvd, tape, diskette - zouden niet lang meer bestaan. Bedrijven die miljarden investeren in glasvezelnetwerken evenmin. Het aloude koperdraadje zou plotseling weer goud waard zijn. Hetzelfde geldt voor gsm. En wat te denken van alle denkbare vormen van consumentenelektronica die beeld en geluid of andere informatie voortbrengen? Niets zou hetzelfde blijven. Het bedrijf met de licenties op SDCS zou, zo stelde Roei Pieper handenwrijvend vast, honderden miljarden dollars waard zijn.

Dan zou het aantal mogelijke films dus gelijk moeten zijn aan het aantal mogelijke codes. Die codes moeten dus werkelijk gruwelijk lang zijn. En guess what? In principe werken we nu exact hetzelfde.

We gebruiken een aantal basisalgorimte voor beeld en geluid (bijvoorbeeld MPEG1/2/4 en MP3/AC3). Als we die algoritmes opslaan hebben we alleen nog maar een code nodig om een film af te spelen. De code kan natuurlijk 'slechts' enkele kilobytes zijn, maar voor een film die uit meer dan 10 miljoen beelden (en biljoenen pixels) bestaat zijn er natuurlijk ziekelijk veel mogelijkheden. Omdat er voor iedere mogelijkheid een key moet zijn worden de codes ook honderen megabytes tot vele gigabytes lang. De code slaan we op in een bestand dat we Film.avi of Video.vob noemen.

[xentric]

quote:

Op zondag 02 juni 2002 00:11 schreef js962 het volgende:
Hier is wat meer info te vinden
http://www.gids.nl/techno/jan-sloot.html

Joh, ze kunnen dat verhaal rechtstreeks naar Spielberg sturen als filmscript, dan verdienen ze er misschien toch nog iets aan

Twee scenarios:
1. Of meneer Sloot heeft 20 jaar zitten broeden op de ultieme scam van de eeuw
2. Of meneer Sloot was werkelijk een genie met een heel bijzondere uitvinding

Ik denk eerder dat scenario 1 in de buurt komt van de waarheid, maar ik zal toch eens wat avondjes gaan nadenken over eventueel andere mogelijkheden voor digitale opslag...

[paradoXical]

quote:

Op zaterdag 01 juni 2002 00:05 schreef Juggalin_Juggalo het volgende:
Oooh, kom op, niet weer die lulkoek van die Philips gast met z'n films in 16Kb Prachtverhaal hoor, maar oh wat een gelul.

Luister, het is onmogelijk een compressie te bedenken die data altijd kleiner maakt.

Op een cd staan 5,9 miljard bits. In die bits kun je 2^{5,9 miljard} mogelijke stukken data opslaan van 700Mb. En je kunt op je kop gaan staan, de bits in het chinees opschrijven, de cd een uur in de magnetron leggen of je hond erop laten schijten, je krijgt er geen één mogelijkheid extra door.

Ook een onzinnige reply.. Bekijk wat er bereikt kan worden wat vroeger voor onmogelijk gegouden zou zou worden.. Ik stel me in dit geval liever wat neutraler op...

Alhoewel ik wel kan snappen dat mensen zich ergeren aan een topic wat al 80 keer langs is geweest

[BadRespawn630]

quote:

Op zondag 02 juni 2002 06:30 schreef HarrieH het volgende:

Alhoewel ik wel kan snappen dat mensen zich ergeren aan een topic wat al 80 keer langs is geweest

Ik verbaas me vooral dat zo veel mensen nu nog niet weten dat het een broodje aap is.

[Juggalin_Juggalo]

quote:

Ook een onzinnige reply.. Bekijk wat er bereikt kan worden wat vroeger voor onmogelijk gegouden zou zou worden.. Ik stel me in dit geval liever wat neutraler op...

Ja, nee, da's wat anders he Jij hebt het nu over technische hoogstandjes of snelheden van cpu's die vroeger onvoorstelbaar waren. Maar in dit geval kan ik wiskundig bewijzen dat er geen compressie bestaat die elke data (eventueel van of vanaf een bepaalde size) comprimeert tot iets kleiners. En dat het verhaal van Sloot dus a priori bullshit is. En niet 'slechts' onuitvoerbaar met de hedendaagse technologie, maar misschien wel met de cpu's van over honderd jaar.

[BadRespawn630]

quote:

Op zaterdag 01 juni 2002 21:10 schreef xentric het volgende:

[..]

Heb je een brilletje nodig ofzo !? Lees eens wat er in de volgende alinea staat...

[Edit]
Even een kleine aanpassing gedaan in italics zodat het nog duidelijker is.

ja goed maar het zijn dus meer dan 21 bits; dmv morse wordt het niet of nauwelijks gecomprimeert.

[xentric]

quote:

Op zondag 02 juni 2002 11:01 schreef BadRespawn het volgende:
ja goed maar het zijn dus meer dan 21 bits; dmv morse wordt het niet of nauwelijks gecomprimeert.

Tja als je zegt dat 1 letter bijvb de "p" 4 tekens lang is ".--." dan is dat inderdaad geen compressie, en als je die vaste pauzes tussen letters niet gebruikt moet je alsnog 4 bits gebruiken per alfabet teken.

Maar ik zei er ook bij dat al je het bitwise bekijkt, je de boel weldegelijk kan comprimeren als je het als bits over een lijn stuurt met een timingcontroller die de "tussen-teken-ruimte" kan detecteren. Ik denk dat de compressie ongeveer 1/2 tot 1/3 is als je grote lappen engelstalige text verstuurd. Nederlandse text heeft al weer iets minder compressie omdat de letter frequency tabel die werd gebruikt om morse te optimaliseren niet helemaal overeenkomt met de nederlandse letter frequency tabel.

[Melkor]

Eventjes voor de zoveelste keer bewijzen dat het niet kan, zoals hierboven ook al tig keer is gedaan.

Als je 2 bits hebt dan zijn er 2² = 4 verschillende stukken data die daarin passen. Stel dat ik een super compressie programma heb dat het mooi comprimeert tot 1 bit. Met 1 bit heb je maar 2 mogelijkheden. Als ik met mijn compressie programma 4 verschillende stukken data zou comprimeren naar sleutels van 1 bit dan krijg ik een probleem. Er zullen een paar dubbele sleutels tussen zitten. En hoe weet ik dan nog welk stuk data bij welke sleutel hoort?

Stel dat ik de volgende 4 stukken data wil inpakken:
code:

data:    sleutel:
     00     1
     01     0
     10     1
     11     0

Wil je de data die bij de sleutel hoort terugvinden dan heb je nog 1 bit nodig. En dan zit je weer aan 2 bits. Je schiet er dus niets mee op....

[Juggalin_Juggalo]

Okee, en deze dan?

Elke groep van 4 bits heeft 2⁴ = 16 mogelijkheden. Door nu niet altijd per se te comprimeren naar 1 bit, maar naar 0, 1, 2 of 3 bit (0 bit is dus een lege file zeg maar) heb je al 2⁰+2¹+2²+2³ = 15 mogelijkheden. Alleen de laatste mogelijkheid moet je dan opslaan als 4 bit. In 15 van de 16 gevallen (94%) win je dus 1 of meerdere bits.

Ik weet trouwens zelf wel dat het niet klopt hoor Maar, wat vind je ervan?

[Varienaja]

quote:

Op maandag 03 juni 2002 10:57 schreef Melkor het volgende:
Eventjes voor de zoveelste keer bewijzen dat het niet kan, zoals hierboven ook al tig keer is gedaan.

Als je 2 bits hebt dan zijn er 2² = 4 verschillende stukken data die daarin passen. Stel dat ik een super compressie programma heb dat het mooi comprimeert tot 1 bit. Met 1 bit heb je maar 2 mogelijkheden. Als ik met mijn compressie programma 4 verschillende stukken data zou comprimeren naar sleutels van 1 bit dan krijg ik een probleem. Er zullen een paar dubbele sleutels tussen zitten. En hoe weet ik dan nog welk stuk data bij welke sleutel hoort?

Je bewijst nu dat compressie niet oneindig door kan gaan, maar waar we allemaal zo nieuwsgierig naar zijn is een andere vraag: krijg je het voor elkaar om alle films van de wereld (maar 3 vind ik ook wel goed) op 1 cd te krijgen?

[Kama]

quote:

Op zondag 02 juni 2002 00:11 schreef js962 het volgende:

...Die laatste code, de sleutel, nam slechts één kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek. Op één simpele chipkaart konden op die manier tientallen sleutels worden opgeslagen. Iemand zou bijvoorbeeld, tegen betaling, met een gsm binnen enkele ...

Wat een onzin. Stel je voor dat ik een film maak van mezelf waarin ik van m'n bed naar de tafel loop. Dit kan ik in beeld brengen vanuit een oneindig aantal camerapunten. Tevens kan ik besluiten om dit in 1, 2, 3, etc. stappen te doen. Daarnaast zou ik ook 1 van de overige miljarden wereldburgers van mijn bed naar mijn tafel kunnen laten lopen.

Met andere woorden, het van m'n bed naar de tafel lopen kan ik op oneindig veel manieren op film zetten. Dit zou betekenen dat er dus ook oneindig veel verschillende sleutels gegenereerd zouden moeten kunnen worden (en dat alleen maar voor dit ene filmpje). De sleutel is een (paar?) kilobyte, dat is eindig. Het is niet mogelijk om met een eindige sleutel oneindig veel combinaties te maken.

Het is dus niet mogelijk.

Met boeken wordt het nog veel duidelijker. Een boek bevat miljoenen tekens. Deze tekens kan ik op vrijwel oneindig veel volgordes opschrijven. Het lijkt me duidelijk dat het niet mogelijk is om een unieke sleutel van enkele kb's te verzinnen voor een unieke combinatie van 20 miljoen tekens uit een boek.

[Juggalin_Juggalo]

quote:

Wat een onzin. Stel je voor dat ik een film maak van mezelf waarin ik van m'n bed naar de tafel loop. Dit kan ik in beeld brengen vanuit een oneindig aantal camerapunten. Tevens kan ik besluiten om dit in 1, 2, 3, etc. stappen te doen. Daarnaast zou ik ook 1 van de overige miljarden wereldburgers van mijn bed naar mijn tafel kunnen laten lopen.

Ja maar die filmpjes zijn er allemaal niet

Natuurlijk kun je niet alle theoretisch mogelijke films comprimeren in 1 KB. Maar alleen kijken naar de films die nu bestaan is ook een optie. Hoe groot zou het aantal unieke films zijn op aarde? Meer dan 4 miljard (=32bit)?

Laten we eens gek doen en er vanuit gaan dat het er hoogstens 18 triljoen zijn (dat is echt HEEL veel). Dan kun je nog steeds elke film op aarde uniek identificeren met slechts 64 bits. Hop, klaar! Ultieme compressie! En als we er gelijk 128bit van maken kunnen we tot het jaar 2400 nog wel vooruit ook.

Nou, moest die Sloot daar nou zo lang over doen?

[Dido]

quote:

Op maandag 03 juni 2002 13:38 schreef Kama het volgende:

[..]

Wat een onzin. Stel je voor dat ik een film maak van mezelf waarin ik van m'n bed naar de tafel loop. Dit kan ik in beeld brengen vanuit een oneindig aantal camerapunten. Tevens kan ik besluiten om dit in 1, 2, 3, etc. stappen te doen. Daarnaast zou ik ook 1 van de overige miljarden wereldburgers van mijn bed naar mijn tafel kunnen laten lopen.

Met andere woorden, het van m'n bed naar de tafel lopen kan ik op oneindig veel manieren op film zetten. Dit zou betekenen dat er dus ook oneindig veel verschillende sleutels gegenereerd zouden moeten kunnen worden (en dat alleen maar voor dit ene filmpje). De sleutel is een (paar?) kilobyte, dat is eindig. Het is niet mogelijk om met een eindige sleutel oneindig veel combinaties te maken.

Het is dus niet mogelijk.

Met boeken wordt het nog veel duidelijker. Een boek bevat miljoenen tekens. Deze tekens kan ik op vrijwel oneindig veel volgordes opschrijven. Het lijkt me duidelijk dat het niet mogelijk is om een unieke sleutel van enkele kb's te verzinnen voor een unieke combinatie van 20 miljoen tekens uit een boek.

Je begrip van oneindigheid is wat beperkt lijkt me. Er is wel degelijk een eindig aantal films (Als je ze tenminste digitaal opslaat ) maar het zijn er wel heel errug veel.

En jij kunt de letters in een boek ookniet in oneindig veel volgordes zetten hoor. Is gewoon eindig voor ieder aantal letters (wel weer errug veel).

[mietje]

Datacompressie: Hoeveel is mogelijk?
Uitvindig van de eeuw.

[Juggalin_Juggalo]

quote:

Je begrip van oneindigheid is wat beperkt lijkt me. Er is wel degelijk een eindig aantal films (Als je ze tenminste digitaal opslaat ) maar het zijn er wel heel errug veel.
En jij kunt de letters in een boek ookniet in oneindig veel volgordes zetten hoor. Is gewoon eindig voor ieder aantal letters (wel weer errug veel).

Ja okee, maar om al die mogelijkheden allemaal een unieke key te geven, moeten je keys zo groot zijn dat ze evenveel ruimte innemen als de film zelf. En zoals al eerder door iemand is opgemerkt, in principe kun je onze films nu ook al zien als 'keys', die dan .avi heten enzo.

[Kama]

quote:

Op maandag 03 juni 2002 13:57 schreef Juggalin_Juggalo het volgende:

[..]

Ja maar die filmpjes zijn er allemaal niet

Natuurlijk kun je niet alle theoretisch mogelijke films comprimeren in 1 KB. Maar alleen kijken naar de films die nu bestaan is ook een optie. Hoe groot zou het aantal unieke films zijn op aarde? Meer dan 4 miljard (=32bit)?

Het maakt niet uit of ze er zijn of niet natuurlijk, het gaat erom dat ze er hadden kunnen zijn en dat je dat onmogelijk in zo'n sleutel kunt vastleggen.

Die sleutel is niet (alleen) een unieke ID, het is zijn de parameters voor die algoritmes. Dus alle kleine verschillen in een film die er kunnen zijn, moeten er in uitgedrukt kunnen worden.

[Dido]

quote:

Op maandag 03 juni 2002 14:07 schreef Juggalin_Juggalo het volgende:

[..]

Ja okee, maar om al die mogelijkheden allemaal een unieke key te geven, moeten je keys zo groot zijn dat ze evenveel ruimte innemen als de film zelf. En zoals al eerder door iemand is opgemerkt, in principe kun je onze films nu ook al zien als 'keys', die dan .avi heten enzo.

Helemaal mee eens hoor ik ben er wel van overtuigd dat die "supercompressie" niet kan. Het ging me er alleen om even die oneindigheid te relativeren. Huidige compressietechnieken werken immers ook op hun best als er niet wordt uitgegaan van een oneindig antal mogelijkheden, maar "heel veel" kunnen ze wel hebben...

[udenjpg]

Gebruik maar eens een goede random-generator en maak hiermee een ASCII file (zeg 2Mb) welke alle mogenlijke ASCII chars gebruikt.
Kijken hoeveel je het kan comprimeren.
Ik gok 0-2 %.

Compressie is 100% afhankelijk van het formaat wat je wilt compressen.

[Kama]

quote:

Op maandag 03 juni 2002 14:02 schreef Dido het volgende:

[..]

Je begrip van oneindigheid is wat beperkt lijkt me. Er is wel degelijk een eindig aantal films (Als je ze tenminste digitaal opslaat ) maar het zijn er wel heel errug veel.

Ik had het ook niet over het aantal films dat bestaat, maar over het feit dat er oneindig veel varianten van een film hadden kunnen zijn (echt oneindig). En iedere daarvan had met zo'n key gecomprimeerd moeten kunnen worden en moeten resulteren in een andere key. Dat kan dus niet.

quote:

En jij kunt de letters in een boek ookniet in oneindig veel volgordes zetten hoor. Is gewoon eindig voor ieder aantal letters (wel weer errug veel).

Volgens mij zei ik hier ook om die reden "vrijwel oneindig", dit deed ook niet af aan het punt dat je een met n tekens nooit zoveel combinaties kunt maken als met n+1 tekens. Dus met een key die bestaat uit n tekens kun je nooit alle mogelijke combinaties ("verschillende boeken") met n+1 tekens onderscheiden.

En dan gaat het er niet om of die boeken er zijn of niet, het gaat er om dat er uiteindelijk altijd wel een boek te verzinnen is dat niet uit te drukken is in die key.

[Kama]

Okay, "vrijwel oneindig" bestaat niet... Lees: knap groot getal (26^20m), iig veeel groter dan die key combinaties kan maken.

[Juggalin_Juggalo]

quote:

Ik had het ook niet over het aantal films dat bestaat, maar over het feit dat er oneindig veel varianten van een film hadden kunnen zijn (echt oneindig).

Volgens mij zijn dat er niet echt oneindig trouwens. Het aantal camerahoeken van waaruit je het kunt filmen is inderdaad oneindig, maar omdat je het opslaat in een eindige resolutie met eindige kleurdiepte (nog afgezien van wat lossy compressie er mee doet) resulteren twee zeer dicht bij elkaar liggende camerahoeken (bijvoorbeeld 1 miljardste graad verschillend) exact dezelfde pixels.

quote:

En dan gaat het er niet om of die boeken er zijn of niet, het gaat er om dat er uiteindelijk altijd wel een boek te verzinnen is dat niet uit te drukken is in die key.

Jep, uiteraard. Naja het was natuurlijk ook een bullshit argument van me. Maar toch, als we nou alle huidige films (en nieuwe films die uitkomen) een unieke 64bit ID geven. Dat gaat een hoop ruimte schelen toch?

[Dido]

quote:

Op maandag 03 juni 2002 14:17 schreef Kama het volgende:
Ik had het ook niet over het aantal films dat bestaat, maar over het feit dat er oneindig veel varianten van een film hadden kunnen zijn (echt oneindig).

Ik denk dat als je de film analoog opneemt het er misschien oneindig veel kunnen zijn, maar digitaal nooit. Uiteindelijk heb je een aantal 1en en 0en die je dus maar op een eindig aantal manieren kan ordenen...

Overigens ben ik het helemaal met je eens wat betreft de onmogelijkheid van het altijd comprimeren op genoemde manier.

Simpel: als je een algoritme hebt waarmee je altijd kunt comprimeren blijf je het gebruiken om je gecomprimeerde data te comprimeren etc... totdat je 1 bit overhoudt??

[udenjpg]

quote:

Op maandag 03 juni 2002 14:27 schreef Juggalin_Juggalo het volgende:
Jep, uiteraard. Naja het was natuurlijk ook een bullshit argument van me. Maar toch, als we nou alle huidige films (en nieuwe films die uitkomen) een unieke 64bit ID geven. Dat gaat een hoop ruimte schelen toch?

Ze hebben nu toch ook een unieke ID, Titel & regisseur. laten we er 1000 chars van maken, dan is het nog een klein ID (en beter te onthouden dan 64Bits).

[Juggalin_Juggalo]

quote:

Simpel: als je een algoritme hebt waarmee je altijd kunt comprimeren blijf je het gebruiken om je gecomprimeerde data te comprimeren etc... totdat je 1 bit overhoudt??

Ja goed is dat he En dan heb ik dus ECHT wel eens lui horen zeggen "Ja, theoretisch kan dat! Dat zijn alleen onvoorstelbaar zware fractalberekeningen, onze huidige computers zijn nog veel te langzaam om dat te kunnen."

[Dido]

quote:

Op maandag 03 juni 2002 14:33 schreef Juggalin_Juggalo het volgende:
Ja goed is dat he En dan heb ik dus ECHT wel eens lui horen zeggen "Ja, theoretisch kan dat! Dat zijn alleen onvoorstelbaar zware fractalberekeningen, onze huidige computers zijn nog veel te langzaam om dat te kunnen."

LOL! Het erge is dat ik me dat levendig voor kan stellen, als ik sommige mensen hoor over computers kunnen ze alles!

Ik heb laatst nog aan iemand uit moeten leggen waarom een hash-checksum wel gebruikt kon worden om te verifieren of een bestand gewijzigd was, maar niet om te vertellen waar die wijziging zat...

Weet je trouwens hoeveel mensen geloven dat ze een unieke PIN hebben?

[Juggalin_Juggalo]

quote:

Weet je trouwens hoeveel mensen geloven dat ze een unieke PIN hebben?

Nee, maar 't zijn er vast meer dan 10000

[Kama]

quote:

Op maandag 03 juni 2002 14:28 schreef Dido het volgende:

[..]

Ik denk dat als je de film analoog opneemt het er misschien oneindig veel kunnen zijn, maar digitaal nooit. Uiteindelijk heb je een aantal 1en en 0en die je dus maar op een eindig aantal manieren kan ordenen...

Daar heb je gelijk in, als je het digitaliseert, maak je het eindig... Dan zou je in theorie nog in de lengte van de film laten varieren, maar een oneindig lange film bestaat niet, die kun je nl niet (geheel) afspelen

[StalieN]

ok mensen
ik ben een dagje weg en meteen moet ik twee pagina's doorploeteren om weer op de hoogte te zijn...

jigalow ofzoiets:
ja ik snap je, m'n berekening was idd fout...

dat idee van 2^32 is 18 triljoen films en dus lekker veel op een cdtje: wel geinig maar dan moet je wel in je cdspeler een chip hebben zitten die 18 triljoen * ca. 700 mB (divx film) aan coderingsgeheugen (hoe heet dat in vakmanstermen..?) heeft omdat anders al die films niet gelezen kunnen worden (een cdspeler moet ook weten dat 10011011 gelijk is aan 155
duss....

kheb in elk geval gezien dat het even kost om een ultieme comprimering te ontdekken
maar ikdenk wel dat het zeker niet onmogelijk is....
als je 200 jaar geleden beweerde dat je ooit binnen een seconde informatie van de andere kant van de wereld kan binnenhalen, werd je in een gesticht gestopt (dit overkwam helaas mijn over-over-grootvader die ik met mijn eigen geconstrueerde tijdmachine een bezoek bracht en hem vertelde dat het zou gaan gebeuren -> door de plaatsing in het gesticht heeft hij uiteindelijk nooit zijn vrouw ontmoet en op papier besta ik dus niet...)

in elk geval een leuke discussie geweest..

[sjorsie]

waarom hebben mensen het hier over digitale opslag?

Kan het niet een ander soort opslag zijn? Zover ik weet had hij een eigen soort computer gemaakt die dat schijffie alleen kon lezen. Dus dan hoeft het toch niet digitaal te zijn?

quote:

als je 200 jaar geleden beweerde dat je ooit binnen een seconde informatie van de andere kant van de wereld kan binnenhalen

Dit kan volgens mij nu nog niet hoor:) 1 seconde is wel erg snel

[Dido]

quote:

Op dinsdag 04 juni 2002 10:26 schreef sjorsie het volgende:
waarom hebben mensen het hier over digitale opslag?

Kan het niet een ander soort opslag zijn? Zover ik weet had hij een eigen soort computer gemaakt die dat schijffie alleen kon lezen. Dus dan hoeft het toch niet digitaal te zijn?

Uit het artikel dat oop de vorige pagina gelinkt werd:

quote:

Op de 64 kB chip van de smartcard staat een code die zestien volledige speelfilms op het scherm van de monitor kan laten verschijnen.
[..]
Jan Sloot liet zien dat hij zestien films op een alledaagse chip kon zetten. Hij beweerde dat er ook 64 films op pasten.
[..]
Je zou met die vinding van Sloot alle films die ooit in de wereld zijn opgenomen, op een cd kunnen zetten.

kB = 1024 x 8 bits = digitaal
een alledaagse chip: een niet digitale chip (fuzzy logic?) is zeker niet digitaal, eerder toekomstmuziek.
een CD = per definitie digitaal ('t ding is vrij precies gedefinieerd.

Het lijkt er dus echt wel op dat het digitaal zou zijn gebeurd hoor. Hoe zie jij trouwens "een ander soort opslag" voor je? Analoog?
Als je natuurlijk een manier vindt om "superbits" te maken die zich in meer dan twee standen kunnen bevinden zou je wellicht "ruimte" kunnen winnen. Maar zoiets wordt nergens genoemd...

[Essence]

quote:

Op dinsdag 04 juni 2002 11:24 schreef Dido het volgende:
Hoe zie jij trouwens "een ander soort opslag" voor je? Analoog?
Als je natuurlijk een manier vindt om "superbits" te maken die zich in meer dan twee standen kunnen bevinden zou je wellicht "ruimte" kunnen winnen. Maar zoiets wordt nergens genoemd...

Nu je je dit afvraagt springt mij ineens het bekende voorbeeld in gedachten van een analoge computer: een plank met zeg 10 spijkers willekeurig erin geslagen. Wanneer je daar zeepsopbellen op blaast, zullen de belwanden die tussen de spijkers gaan staan een oplossing vormen voor het travelling salesman probleem gevormd door die spijkers.
Basis voor zo'n analoge opslag zou dus m.i. iets heel simpels kunnen zijn dat op een bepaalde ge-enabled (hier met het blazen van zeepbellen erop) wordt zodanig dat er effectief niet een TSR oplossing/berekening op analoge wijze plaatsvindt, maar dat er effectief gecompressed/decompressed wordt?

[DocMac]

Is dit niet gewoon een uit de hand gelopen roddel over dit nieuwsbericht?

http://www.tweakers.net/nieuws/21986

[Yoozer]

quote:

Op dinsdag 04 juni 2002 10:26 schreef sjorsie het volgende:
waarom hebben mensen het hier over digitale opslag?

Kan het niet een ander soort opslag zijn? Zover ik weet had hij een eigen soort computer gemaakt die dat schijffie alleen kon lezen. Dus dan hoeft het toch niet digitaal te zijn?
[..]

Dit kan volgens mij nu nog niet hoor:) 1 seconde is wel erg snel

even lullig zijn - ik krijg google in 1 seconde binnen. 'informatie' kan al bestaan uit een pakketje, dus een ping van 300ms ligt al onder 1 seconde. don't understimate the speed of light .

[Essence]

quote:

Op dinsdag 04 juni 2002 11:54 schreef Yoozer het volgende:
don't understimate the speed of light .

Like you shouldn't underestimate the bandwith of a truck full of CD-ROM's (niet tegen op te FTP-en).
Signaal snelheid in glasvezel en in goed geleidend metaal is bijna lichtsnelheid, dus zo'n 7x rond de aarde in 1 seconde.

[StalieN]

Info uit Amerika kan makkelijk met 1 seconde hoor! (lees bovenstaande 2 reacties maar...)

Dat idee van analoge data is misschien wel het antwoord...
Een schijf met een soort chemische stof erop die onder een bepaalde lichtval verschillende kleuren kan reflecteren.
Als er 4 verschillende kleuren te herkennen zijn dan kan dit al 2 bits vertegenwoordigen: 00, 01, 10, 11 = 2^2
misschien zijn er zelfs 3 kleuren... 2^3 000, 001, 010, 011, 100, 101, 110, 111 dus dat zijn al 8 mogelijkheden.

Was deze Jan Sloot toevallig een chemicus dat iemand weet..?
Kijk... in dit soort gevallen zou het toch handig zijn als er een persoonlijke database van elke bewoner in heel Nederland zou worden bijgehouden waar je zo even de opleiding kon vinden...

Als hij 20 jaar is bezig geweest, dan ligt het antwoord klaarblijkelijk (ooooud-nederlands...) niet voor de hand.

Maar als we nou met 20 man hard denken dan zijn we er over een jaartje

[spacy]

als een film 30fps zou zijn bestaat een film uit 216k frames,
met zoveel films op 1 cd blijft er een maar paar kb over voor duizenden frames
sorry hoor maar dit lijkt mij toch echt onmogelijk, met de meest zware compressie of formules gebruikt.

ik heb wel divx gezien, die zijn aangepast aan resolutie en framerate van pdatjes (casiopedia 200 geloof ik)
en dan past precies een filmpje op 128 mb compactflash.

maar dat ziet er niet meer leuk uit op een tv

[Dido]

quote:

Op dinsdag 04 juni 2002 13:04 schreef StalieN het volgende:
Dat idee van analoge data is misschien wel het antwoord...
Een schijf met een soort chemische stof erop die onder een bepaalde lichtval verschillende kleuren kan reflecteren.
Als er 4 verschillende kleuren te herkennen zijn dan kan dit al 2 bits vertegenwoordigen: 00, 01, 10, 11 = 2^2
misschien zijn er zelfs 3 kleuren... 2^3 000, 001, 010, 011, 100, 101, 110, 111 dus dat zijn al 8 mogelijkheden.

Dat is dus nog steeds digitaal
Bij analoog heb je een oneindig aantal mogelijkheden (theoretisch in ieder geval, maar iig véél meer dan 2 of 3!)
Overigens: 4 kleuren zou 2 bit zijn, correct
bij 3 kleuren raak je de draad een beetje kwijt:
Met 8 (!) kleuren kun je drie bits opslaan. (Of andersom, met 3 bits kun je act waardes weergeven )
Leuk ideetje, maar om 16 bits weer te geven in 1 "gekleurde superbit" (compressiefactor 16 dus) heb je 65536 kleuren nodig...

Nogmaals: als er een methode zou zijn die gegevens altijd verder kan comprimeren, dan zou je door kunnen gaan tot je divx nog maar 1 bit groot is. Elke divx, altijd. Is 0. Of 1. En dat kan niet, en dus is de oorspronkelijke aanname fout. Er is dus geen methode die altijd gegevens kan comprimeren. Niet dat we die nog moeten ontdekken, hij is er gewoon niet!

[Varienaja]

quote:

Op dinsdag 04 juni 2002 13:30 schreef spacy_ het volgende:
als een film 30fps zou zijn bestaat een film uit 216k frames,
met zoveel films op 1 cd blijft er een maar paar kb over voor duizenden frames
sorry hoor maar dit lijkt mij toch echt onmogelijk, met de meest zware compressie of formules gebruikt.

Bij een compressiemethode hoef je natuurlijk niet per se ieder frame los op te slaan. Je zou bijvoorbeeld kunnen zeggen: de achtergrond staat stil (1 frame), en een klein voorwerp beweegt van links naar rechts (25 frames van 1/25e van het originele formaat).

Je slaat nu dus 1+25 * 1/25e op. Dat is 2 frames, terwijl het origineel 25 frames was.

Bij mp3 wordt ook niet iedere losse sample gecomprimeerd opgeslagen. Dan zou je uitkomen op iets van 0,8 bits per sample. Onzin natuurlijk.

[commodore]

Is het niet mogelijk om bij een cd niet gewoon meer met putje of geen putje te werken maar strepen van verschillende lengten te nemen? Als je dat nog eens samen neemt met verschillend kleuren en verschillende dieptes kan er wel heel veel data op een schijfje.

[Skimmer]

quote:

Op dinsdag 04 juni 2002 14:39 schreef Varienaja het volgende:

[..]

Bij een compressiemethode hoef je natuurlijk niet per se ieder frame los op te slaan. Je zou bijvoorbeeld kunnen zeggen: de achtergrond staat stil (1 frame), en een klein voorwerp beweegt van links naar rechts (25 frames van 1/25e van het originele formaat).

Je slaat nu dus 1+25 * 1/25e op. Dat is 2 frames, terwijl het origineel 25 frames was.

Ooooww.... wat goed van jouw... je hebt Mpeg compressie (her)ondekt...

[Varienaja]

quote:

Op dinsdag 04 juni 2002 19:21 schreef Skimmer het volgende:
Ooooww.... wat goed van jouw... je hebt Mpeg compressie (her)ondekt...

Nee, ik heb uitgelegd dat film-compressie niet beeld-voor-beeld werkt.

[Vertex|IA]

Ik heb deze hele discussie niet gevolg, maar ik wil toch het volgende opmerken:

quote:

Dido :
Bij analoog heb je een oneindig aantal mogelijkheden...

Dit is niet waar. Je hebt wel meer mogelijkheden t.o.v. een digitale methode, maar die analoge methode is ook gewoon eindig.

[55563]

Die enorme compressie die bereikt zou kunnen worden, geloof ik niet zo. Maar dat er steeds meer informatie op een schijfje zo groot als een cd past, is geen schrikbarend nieuws:

CD -> 700 MB (infrarode laser)
DVD -> 4 GB (rode laser)

En dan over een jaar of 2 de opvolger van de DVD, de blu-ray disc: 27 GB per laag !!



Werkt met een blauwe of zelfs violette laser.

Omdat dus de golflengte van het laserlicht steeds verder afneemt, kunnen ook de putjes op het schijfoppervlak steeds kleiner worden, waardoor automatisch de informatiedichtheid toeneemt.

[pirke]

iedereen denkt bij zijn oplossing aan comprimeren, maar wat als je het van een andere hoek gaat bekijken?

om meer data op te slaan hoeft de data niet perse kleiner te worden, als de beschikbare opslagruimte maar groeit.

misschien had hij een manier gevonden om de gewone transistor (of combinatie van verschillende transistoren) aan te passen (op welke manier dan ook) dat er efficienter data opgeslagen kan worden.

stel deze techniek is heel breed bruikbaar (en dus heel waardevol, want een megacompressie systeem vind ik niet zo geweldig dat iedereen er honderden miljarden in wil steken) is en ook toepasbaar is op combinaties van putjes in een cd of wat dan ook, dan kan ik me wel voorstellen dat iedereen er gebruik van wil maken.

waarschijnlijk zijn er nog genoeg andere invalshoeken, wie weet?

[Dido]

quote:

Op woensdag 05 juni 2002 00:44 schreef Vertex het volgende:
Ik heb deze hele discussie niet gevolg, maar ik wil toch het volgende opmerken:
[..]

Dit is niet waar. Je hebt wel meer mogelijkheden t.o.v. een digitale methode, maar die analoge methode is ook gewoon eindig.

Ik heb het over een ideale analoge methode. En dan zijn de mogelijkheden oneindig. Als je je precisie maar genoeg verhoogt. In de praktijk is precisie wel aan een limiet gebonden en kun je geen enkel proces echt analoog opslaan.
Wel geldt weer dat de mogelijkheden zo groot kunnen zijn dat ze praktisch wel weer als oneindig worden beschouwd.

[Dido]

quote:

Op woensdag 05 juni 2002 03:30 schreef pirke het volgende:
iedereen denkt bij zijn oplossing aan comprimeren, maar wat als je het van een andere hoek gaat bekijken?
om meer data op te slaan hoeft de data niet perse kleiner te worden, als de beschikbare opslagruimte maar groeit.

De beste man stopte

quote:

een witte smartcard met een 64 kilobyte chip in het daarop aangesloten apparaatje

volgens het artikel op p.2
Het gaat dus niet om meer geheugencapaciteit van de drager, maar om compressie.

Als hij gewoon een revolutionaire nieuwe manier van data opslag had gevonden, zou het hele verhaal over films ook niet zo relevant zijn. In tegenstelling tot de belevingswereld van sommige mensen is het opslaan van films in digitale vorm niet een van de belangrijkste toepassingen van grote hoeveelheden snel geheugen.
Als de beste man met een smartcard van 4TB naar binnen was gewandeld bij IBM was-ie zo binnen geweest hoor! Hoeft-ie geen filmpjes te laten zien.

Overigens zijn we in zo'n 40 jaar van 360KB floppen naar 80GB harddisks gegaan wat betreft snelle opslag. Zo'n 2 miljoen keer groter dus. Dat lijkt veel, maar dan hebben we nog erg lang nodig om alle films op een diskje op te slaan met de huidige compressiemethoden...

[Vertex|IA]

quote:

Dido :
Ik heb het over een ideale analoge methode. En dan zijn de mogelijkheden oneindig.

Die ideale analoge methode waar jij het over hebt bestaat niet, zelfs theoretisch niet.

[Dido]

quote:

Op woensdag 05 juni 2002 12:21 schreef Vertex het volgende:
Die ideale analoge methode waar jij het over hebt bestaat niet, zelfs theoretisch niet.

Voor opslag niet... hoewel: Een draaiorgel komt aardig in de buurt. Alleen kune je de gaten in de papierband niet echt oneindig veel verschillende lengtes geven omdat het papier is. Met theoretisch perfect papier zou dat dus wel kunnen.
Voor processen lopen de meningen wat uiteen. Maar dat is een andere discussie
Ik haalde het alleen maar aan omdat iemand stelde dat je digitaal oneindig veel mogelijkheden had...

[Sandalf]

Hoax... Het heeft in de kranten gestaan, maar het bleek een hoax te zijn.

[55563]

quote:

Op woensdag 05 juni 2002 12:21 schreef Vertex het volgende:

[..]

Die ideale analoge methode waar jij het over hebt bestaat niet, zelfs theoretisch niet.

Ik kan wel een theoretisch ideale analoge methode verzinnen. Je zou bijv. een cd kunnen nemen waarbij de diepte van een putje de informatie bevat. Dus zoveel verschillende dieptes als er tekens nodig zijn op een pc. Dan heb je opeens geen 8 putjes meer nodig om een byte op te slaan, maar slechts 1 .

[Dido]

quote:

Op donderdag 06 juni 2002 14:18 schreef rsmit het volgende:
Ik kan wel een theoretisch ideale analoge methode verzinnen. Je zou bijv. een cd kunnen nemen waarbij de diepte van een putje de informatie bevat. Dus zoveel verschillende dieptes als er tekens nodig zijn op een pc. Dan heb je opeens geen 8 putjes meer nodig om een byte op te slaan, maar slechts 1 .

Dan moet je alleen geen bytes op gaan slaan

[Vertex|IA]

Het ging om de vraag of een analoge methode oneindig veel mogelijkheden geeft, en ik kan je vertellen dat dat niet zo is. Een analoge methode is altijd eindig, omdat atomen nou eenmaal een grootte hebben.

[Juggalin_Juggalo]

quote:

Een analoge methode altijd eindig, omdat atomen nou eenmaal een grootte hebben.

Nee, want je zou bijvoorbeeld ook een getal kunnen vastleggen in de hoek waaronder het ene atoom ten opzichte van het andere ligt. En 0 tot 360 graden kun je wel opdelen in oneindig veel stapjes.

Bovendien is het geloof ik de vraag of ons huidige atoommodel wel correct is, dat idee van Bohr met z'n bolletjes met schillen/lagen waarin electronen zweven enzo is handig om in gedachte te houden, maar niet meer dan een menselijke representatie.

Hey we dwalen nu wel een beetje af he. Een aantal lui halen hier compressie en verbetering van medium door elkaar. Het probleem was, dat je amper 1 film op een CD (lees: 700Mb) kan proppen. Jan Sloot claimde daar een oplossing voor te hebben, waardoor een film in 16Kb (of die orde van grootte) gepropt kon worden, en naar ik aanneem in fatsoenlijke kwaliteit ook nog (anders kan het nu ook wel, maar dan ga je van de film geen reet meer herkennen).

Allerlei vage ideeën over DVD's met 6 dubbelzijdige lagen, analoge putjes en blauwe lasers zijn leuk, maar dat is geen compressie natuurlijk. Dat is alleen je medium aanpassen (c.q. verbeteren) zodat er meer bits op passen. De stap van CD naar DVD was ook geen compressie.

Een medium hoeft op zich niet per se met bits te werken natuurlijk, maar computers zijn digitaal dus op het moment dat de data van je medium je computer binnenkomt is het digitaal. De opslagcapaciteit van een medium kan dus wel worden uitgedrukt in bits.

Bij compressie hoeven we dus alleen in bits te denken. Hoe slaan we zoveel mogelijk informatie op in zo min mogelijk bits. Allerlei 'fysische' aspecten als putjes en draaiorgelkaarten doen daarbij niet terzake, het gaat alleen om het compressie algoritme.

Een 'ultieme' compressie die alle data die je erin propt kleiner krijgt, bestaat niet. Sterker nog, bij elke compressie kan ik een blok data verzinnen wat door die compressie groter wordt.

En een gemiddelde speelfilm op acceptabele kwaliteit in 16Kb persen, lijkt me ook onmogelijk. Theoretisch kun je het niet weerleggen (zoals wel kan met dat idee van een 'ultiem' compressie algoritme), maar gezien de datadiversiteit van twee uur beeld en geluid lijkt het me niet realistisch.

[jonathandb]

quote:

Op donderdag 06 juni 2002 18:04 schreef Juggalin_Juggalo het volgende:

[..]
En 0 tot 360 graden kun je wel opdelen in oneindig veel stapjes.

In theorie wel maar in de praktijk niet omdat er zoiets is al een minimale energie hoeveelheid (zoek maar eens op "constante van planck) En angezien je energie nodig zal hebben om de hoek in te stellen zal je deze hoek dus alleen in kleine stapjes kunnen instellen en dus een eindige hoeveelheid.

[Melkor]

quote:

Op donderdag 06 juni 2002 18:04 schreef Juggalin_Juggalo het volgende:

[..]

Een 'ultieme' compressie die alle data die je erin propt kleiner krijgt, bestaat niet. Sterker nog, bij elke compressie kan ik een blok data verzinnen wat door die compressie groter wordt.

En een gemiddelde speelfilm op acceptabele kwaliteit in 16Kb persen, lijkt me ook onmogelijk. Theoretisch kun je het niet weerleggen (zoals wel kan met dat idee van een 'ultiem' compressie algoritme), maar gezien de datadiversiteit van twee uur beeld en geluid lijkt het me niet realistisch.

Je kunt idd niet elk willekeurig stukje data inpakken. Ik dat dat de gemiddelde factor waarmee je een willekeurig stukje data in kan pakken 0% is. Maar er zullen ook stukjes zijn die je 99% kan inpakken. Maar wat je op dat stuk data aan geheugen wint verlies je weer op een ander stuk. Even een voorbeeldje met wat getallen, dat verduidelijkt de boel meestal wel iets.

We nemen 4 stukjes data van 2 bit. (Dus alle mogelijke vormen van 2 bit.) De linker kolom zijn de stukjes data voor de compressie en rechts is de data na de compressie
code:

voor    na
00   -> 0
01   -> 010
10   -> 101
11   -> 1

2 stukjes konden goed worden ingepakt. Ze hadden namelijk een grote regelmaat. 2 nullen of 2 enen. De andere 2 stukjes konden niet worden ingepakt. Ze hadden een maximale entropie _{(ik dacht dat het zo heette)}. Er is geen patroon in te herkennen en dus kan het niet ingepakt worden. De gemiddelde compressie factor is dus 0%. Het kan ook niet anders, want als ik bijvoorbeeld 3 stukken data van 2 bit in kan pakken tot 1 bit dan zit er een dubbele bij:
code:

00 -> 0
01 -> 1
10 -> 101
11 -> 1

Als ik die '1' uit ga pakken weet ik niet of het '01' of '11' moet worden.

Nu weer ff over die films. Een film is niet 2 bit maar 700Mb. 700Mb is 700 * 8 * 2²⁰ = 5872025600 bits.
Er zijn dus 2^5872025600 mogelijke stukken data van 700Mb. Dat zijn er heeeeeeel veel. En daarvan is slechts een miniscuul deel een film. Dus het zou heel goed kunnen dat je een film van 700Mb in kan pakken tot 16kb, maar dat houd wel in dat er een hele hoop stukken data zijn die je helemaal niet in kan pakken. En het houdt ook nog in dat films een hele lage wanorde hebben. Er moeten dus hele duidelijke patronen in de bestanden zitten anders kun je het nooit zo goed in pakken.

[unteraarsch]

Hoe en hoe goed je data in kan pakken hangt volledig af van het type data en de hoeveel data je hebt.

Een plaatje van 200x200 die helemaal groen is kun je natuurlijk supergoed inpakken, "200,200,groen" zou het hele plaatje beschrijven. Hoe ingewikkelder de data hoe moeilijker het word en hoe minder resultaat je krijg.

Ik heb ooit gelezen over een compressie methode die bepaalde data een factor honderd kleiner maakte!! dat is ongeloofelijk veel, De voorwaarde ervoor was dat er wel terrabytes aan gegevens waren en dat het een speciaal soort data was (ik geloof seismogarifische onderzoeksresultaten ofzo).

Dus als je veel data hebt en je weet in welke vorm het ongeveer voorkomt kun je betere compressie methoden verzinnen. Vandaar dat er ook zoiets is als mp3 en jpeg e.d.

Daarom denk ik ook dat de compressie methoden nog lang niet uitgeput zijn. Het is maar net wat er ingepakt moet gaan worden.

(net als programmeren, het gebruik van sub-routines is ook een soort compressie, wat soms een factor 100000... kan schelen. Hetzelfde geld voor vectoren ipv bitmaps)

[jonathandb]

quote:

[b]Op donderdag 06 juni 2002 20:00 schreef
Ik heb ooit gelezen over een compressie methode die bepaalde data een factor honderd kleiner maakte!! dat is ongeloofelijk veel, De voorwaarde ervoor was dat er wel terrabytes aan gegevens waren en dat het een speciaal soort data was (ik geloof seismogarifische onderzoeksresultaten ofzo).

Ja klopt, heeft ooit in de Kijk gestaan heeeeel lang geleden

[pirke]

quote:

Op donderdag 06 juni 2002 19:04 schreef Melkor het volgende:

[..]

Nu weer ff over die films. Een film is niet 2 bit maar 700Mb. 700Mb is 700 * 8 * 2²⁰ = 5872025600 bits.
Er zijn dus 2^5872025600 mogelijke stukken data van 700Mb. Dat zijn er heeeeeeel veel. En daarvan is slechts een miniscuul deel een film.

in theorie zijn dat dus 2^5872025600 films... niet dat je alle verschillen merkt, 1 bitje anders, niemand ligt er wakker van. maar stel we hebben meer films dan 2^{1024 * 8 * 16} dan is het al niet meer mogelijk om alle films in 16 kb op te slaan.

stel hij heeft een functie die uit dat grote aantal films (maar wel veel minder dan 2^5872025600 aangezien je de meeste wijzigingen niet ziet) de juiste pakt door de identifier op te slaan in die 16 kb?

dan zou je een functie moeten hebben die dus 700mb aan data kan genereren op basis van 1 beginwaarde.

ook zijn films niet zo maar willekeurige data, dat zie je aan de compressie die we tegenwoordig al hebben.

en ik bedenk me net dat die functie + identifiers bij elkaar ook 700mb mogen zijn, zolang het samen maar op 1 cd past...

mijn mening: er zal vast een kern van waarheid inzitten, maar erg sterk klinkt het wel... beetje te sterk.

[lvh]

quote:

Op zaterdag 01 juni 2002 20:32 schreef xentric het volgende:

[..]

Als je nou eens een stuk papier pakt en een paar simpele stappen van jouw 9-bits techniek doorrekend, en vervolgens terug gaat rekenen naar de originele data dan zal je zien dat je nergens komt. Ik snap je hele 9-bits idee trouwens nog niet helemaal... Wat wil je nu met zo veel tekens. Wat heeft dat voor nut?

Als je kijkt naar bijvoorbeeld zip-compressie dan werkt dat gewoon met een soort library van veel voorkomende stukken data in de te comprimeren file. Er wordt voor die stukken code een zo kort mogelijke vervangende code gegeven. En wat een van de vorige posters bedoelde is dat je met zo'n compressie na een paar rondjes al zoveel random data hebt dat er geen optimalisatie meer uit het gebruik van een library, met veel voorkomende data, te halen is. Snappie !?

Morse-code is bijvoorbeeld op hetzelfde principe gebaseerd. Als je een letter-frequency-tabel naast een tabel met de morsecodes legt dan zie je waarom bijvoorbeeld [e=.] [i=..] [t=_] de meest voorkomende tekens, zo kort mogelijk zijn om het verzenden te optimaliseren. Bitwise gezien pas je dus compressie toe want een [e] is maar 1 bit in plaats van 4 bits en omdat de [e] het vaakst voorkomt in teksten is de compressie van die letter dus optimaal.

Voorbeeldje:

Als we de string [abcdefg] omzetten met een 5 bits tekenset (genoeg voor lowercaps alfabet) dan krijgen we:
[00001|00010|00011|00100|00101|00110|00111] en dat zijn dus 35 bits. Als we vervolgens de morse techniek toepassen met een vaste tijdseenheid tussen letters dan krijgen we:
[.-|-...|-.-.|-..|.|..-.|--.] en dat zijn inprincipe 21 bits als we de reeks zouden schrijven als [01|1000|1010|100|0|0010|110]

Hier heb je dus een lossless compressie toegepast als je ervanuitgaat dat de hardware rekening houd met een vaste pauze tussen de bits van iedere letter om een volgende letter te kunnen onderscheiden. Dus door van pauzering technieken gebruik te maken kunnen we extra comprimeren omdat een letter zelfs 1 bit groot mag zijn.

(even voor de duidelijkheid, ik heb het hier over compressie voordat de data de lijn op gaat, dus een transmissie-compressie)

Maar de bovenstaande string voldoet niet helemaal aan de vaste library die voor morse geldt. Als je betere compressie van deze string wilt hebben dan zou je een nieuwe indeling moeten maken adhv de te comprimeren data. Dit is wat zip-compressie dus ook doet. Het probleem bij zo'n kleine string is dus dat je die nieuwe library moet toevoegen om te kunnen decoderen, en dan is het denk ik zelfs groter dan ongecodeerd. Dus het blijft schipperen met wat nou optimaal is.

Nou, probeer maar eens wat op papier, of probeer een simpele programmeertaal zoals turbo-pascal te leren waarmee je makkelijk en zeer snel al je ideeen kan testen. Je zal zien, comprimeren is moeilijker dan het lijkt!

Kan al gezegd zijn maar:

Met morse schiet je dus ook nog NIX op. Neem het nu aan, wiskundig gezien kan je met 2⁸ aan data gewoon enkel 256, en geen teken meer, onthouden.

Morse helpt je niet, en eigenlijk om dezelfde reden dat het 9bits verhaal je niet helpt. Waarom? Denk es na. Heeft Morse 256 mogelijke getallen? Juist. Nee. 26 plus wat punctuatie en dingen als fout, goed, goed ontvangen enzo

[Arnout]

Schopje, vrijdagavond is opnieuw aandacht besteed in een documentaire (heb het zelf helaas niet kunnen zien), er is nu ook een boek verschenen over deze mogelijke "uitvinding". Het boek heet "De Broncode". Er blijven toch een aantal zaken vreemd aan dit verhaal.

• Jan Sloot is op vreemde wijze om het leven gekomen. Misschien zelfmoord (omdat het idee niet deugde), maar misschien ook om andere redenen.
• Philips topman Roel Pieper is niet lang daarna vertrokken bij Philips

Je moet je niet blindstaren op de "compressie" waar het om zou gaan. De theorie is gebasseerd op een soort "hash", een sleutel, die gedecodeerd uitsluitend resulteert in een databestand ter grootte van een film. De sleutel zelf niet groter dat een (paar) kilobyte. Het is dus niet het inpakken van een gif plaatje d.m.v. gelijke karakters of patronen te verkleinen.

Verder nog even wat links (weet niet of het al voorbijgekomen was):


Netwerk "De Broncode": http://www.netwerk.tv/ind...=items&r=netwerk&a=131361
Quote artikel: http://www.gids.nl/techno/jan-sloot.html
UT Twente Nieuws: http://wwwutnws.utwente.nl/utnieuws/data/36/6/ROEL.html

Arnout wijzigde deze reactie 13-09-2004 12:23 (23%)

[Zoijar]

quote:

MetHod schreef op 13 september 2004 @ 12:13:
Je moet je niet blindstaren op de "compressie" waar het om zou gaan. De theorie is gebasseerd op een soort "hash", een sleutel, die gedecodeerd uitsluitend resulteert in een databestand ter grootte van een film.

Hmmm dat is compressie Gaat dit ook echt om opslag op nu bestaande binaire media? Het is dus niet zo dat hij een betrouwbare 8 (n) waardige cd/dvd oid heeft uitgevonden? Het is een puur theoretisch iets waar het om gaat toch? Een wiskundige manier om een film, dwz een 3d matrix, te comprimeren. En verder zijn deze matrices redelijk willekeurig; een grote kolomogorov complexiteit dus.

Het moet dan wel lossy zijn als ik het zo lees, want anders zou je denk ik tegen de shannon grens aanlopen. Dus al die vergelijken met zip (lzw) etc gaan niet op.

Voor de discussie, hoe lossy compressie nu werkt (bv jpeg2000) is als volgt. Je ziet je data als een vector. Je transformeert deze met een bepaalde wavelet transform. Zie dit als een fourier transformatie. Het punt is dat van de coefficienten van de getransformeerde vector een groot aantal nul of dicht bij nul zijn. Slechts een klein percentage is "groot". Een klein deel dus "draagt informatie" (energie). Nou is de fout die je introduceert in deze vector, gelijk aan de fout als je hem terug transformeert (decompressed). Het merendeel van de dicht bij nul coefficienten kan je dus op nul zetten. (lossy compressie stap) Het punt is nu om deze "paar" coefficienten op een slimme manier op te slaan. Bv met een bitmap voor wat er nul is, en die hoef je dan niet op te slaan; of in een speciale hash tabel. (in de praktijk: zero-tree coding, lossless compressie stap)

Wat kan er nu uitgevonden zijn? Bv een sterk verbeterde wavelet transformatie, die de vector nog meer kleine coefficienten geeft. Of een sterk verbeterde zero-tree coding. Hoewel dat er niet in zit, omdat de bestaande lossless technieken al tegen de theoretische grens aanzitten.

[Captain Proton]

Dit is wel een heel grote schop... Degenenen die hier 2 jaar geleden over discussieerden zullen echt niet meer gaan reageren. Daarom gaat dit topic op slot. Bov endien loopt er hierover al een topic in NSTM. Dat gaat weliswaar voornamelijk over de complottheorieen om deze vinding heen en niet over de wetenschap erachter, maar aangezien die wetenschap, als hij er al is, verloren gegaan is, valt daar geen wetenschappelijke discussie over te voeren. Mocht je een topic willen starten over compressie en de theoretische limieten daaraan, dan kan dit natuurlijk wel in W&L.