sciencetalk

Het gaat in dit topic veel over films. Ik wil het gewoon in het algemeen over data-opslag hebben en houd het abstract.

Volgens mij heb ik een goed idee. Ik weet niet of het nieuw is, want ik heb niet alle voorgaande posts helemaal begrepen.

Op maandag 10 januari schreef Boaz:

Hoe krijg ik een getallenreeks logisch kleiner zo dat ik hem laten ook weer groter kan krijgen. Als je dat voor elkaar kijgt doe ik de rest.

Welnu; binair data opslaan is eigenlijk helemaal niet efficient. Volgens mij kun je veel efficienter informatie digitaal opslaan door het beter te ordenen. Als je informatie niet meer opslaat als bits, maar als clusters van bits, zijn er in theorie onbeperkt veel mogelijkheden.

Bij normale binaire opslag is een bit een 1 of een 0.

Als je info opslaat in clusters van 2 bits, kan zo’n cluster 4 verschillende waarden hebben: 00, 01, 10 en 11. Dus netto heb je dan een verdubbeling van de geheugencapaciteit.

Als je info opslaat in clusters van 3 bits, kan zo’n cluster 8 verschillende waarden hebben: 000, 001, 010, 100, 011, 110, 101 en 111. Dus netto heb je dan 8/3 keer de oorspronkelijke geheugencapaciteit.

Als je clusters van 5 bits gebruikt, heb je per cluster 32 mogelijkheden, wat resulteert in een “geheugencapaciteitstoenamefactor” van meer dan 6.

Als je clusters van 100 bits gebruikt, heb je per cluster 1,27 *10^30 mogelijkheden, wat resulteert in een “geheugencapaciteitstoenamefactor” van 1,27 *10^28!

Je hebt alleen een algoritme nodig om deze manier van opslaan te decoderen. Hoe groter de clusters, des te ingewikkelder het decoderen, maar het moet mogelijk zijn.

Ik hoor graag reacties of ik ergens een denkfout heb gemaakt.

willard schreef:Het gaat in dit topic veel over films. Ik wil het gewoon in het algemeen over data-opslag hebben en houd het abstract.

Volgens mij heb ik een goed idee. Ik weet niet of het nieuw is, want ik heb niet alle voorgaande posts helemaal begrepen.

"Algemene" ideeën werken niet. Je kunt data niet in het algemeen kleiner maken. Je idee is in een iets andere vorm al eerder aan de orde geweest, zie hier en hier.

Wil je op dit gebied een doorbraak maken, dan zal dat óf neerkomen op een nieuwe fysieke manier van dataopslag, dus iets met een veel hogere informatiedichtheid dan de huidige harddisks, optische media of flash geheugen, óf op een nieuwe methode om een bepaalde soort data (zoals films of muziek) efficiënter in te pakken. Voor de tweede mogelijkheid zal alleen lossy compressie, die dus per definitie heel specifiek voor één soort data gemaakt is, nog verbetering kunnen brengen.

Ik hoor graag reacties of ik ergens een denkfout heb gemaakt.

In clusters van 2 of 3 of N bits kun je uiteraard meer informatie kwijt dan in 1 bit. Alleen daar heb je niets aan, want in vergelijking met losse bits kost het ook 2 of 3 of N keer zoveel ruimte of bandbreedte om zulke clusters fysiek op te slaan of te verzenden.

Verder maak je een rekenfout: een cluster van N bits kost N keer zoveel ruimte als 1 bit, en kan 2^N verschillende waarden hebben (in tegenstelling tot de 2 waarden die één enkele bit kan aannemen). Dat klopt. Maar het aantal verschillende waarden dat een informatie-eenheid kan aannemen, komt niet overeen met de opslagruimte of bandbreedte die je nodig hebt om die eenheid op te slaan of te verzenden. Of je nu N losse bits opslaat of verstuurt, of één cluster van N bits: het aantal mogelijke verschillende waarden die je kunt verzenden blijft 2^N.

In het geval van losse bits komt er niet één mogelijkheid bij per bit die je toevoegt, het aantal mogelijkheden verdubbelt.

Coderen is ankeren.

De eerste byte die we lezen ankert aan een afspraak.

Deze 1e byte kan dan 256 afspraken herbergen omtrent de komende bytes.

Bijvoorbeeld een melkfabriek:

die heeft vla,yoghurt, melk, karnemelk, volle melk, boter, halvamel, koffiemelk, kaas, belegen kaas.

Om al deze produkten te coderen heeft men nodig het getal 1 t/m 10.

Als men van elke produktiedag, 5 in de week, het aantal geproduceerde wilt opslaan dan moet men de melk uitdrukken in liters, de kaas in onsen etc.

Hierover maakt men afspraken. Men ankert de data aan afspraken.

Nu produceert die fabriek niet tig miljoenen liters melk maar een eenheid van maximaal 2 bytes.

Dus voor de produktiemelk heeft men maar 3 bytes nodig.

(als de produktie boven de 2^32 uitsteekt dan past men een correctie-data element toe, kost dan 2 bytes extra)

Men kan een code toewijzen bijvoorbeeld 255 om te zeggen dat er nu een vaste lijst wordt overgedragen:

melk, kaas, boter, koffiemelk.

Dan kost dat lijstje maar 9 bytes i.p.v. 12 bytes. (3 bytes gewonnen)

Bij 30 produkten * 3 bytes per dag *5 *52 kan men een geheel jaar opslaan in 23400 bytes plus 260 dagcode plus afspraakcode.

Door de vaste lijst toepassing kan men daarop nog eens 780 bytes besparen.

Is een heel verhaal maar zo kan men coderen.

Op een 1 meg schijfje past dan ongeveer 43 jaar aan produktiecijfers.

Gaat men het opslaan door middel van tekst en tekstcodering dan had men nodig:

((30*3*6)+(30*5))*5*52=179400 bytes.

Zeg maar 180000 inclusief de dag codering.

Op een 1 meg schijfje past dan nog maar: 5.5 jaar.

Dat is ongeveer een faktor 8 door gebruik te maken van codering die past naar het produkt toe.

Een compressie toepassen die getallen comprimeert kan alleen domme data (Microsoft presteert het om 256 nullen vooraan een databestand neer te zetten) goed comprimeren.

rogier schreef:

Maar het aantal verschillende waarden dat een informatie-eenheid kan aannemen, komt niet overeen met de opslagruimte of bandbreedte die je nodig hebt om die eenheid op te slaan of te verzenden.

Dit snap ik niet helemaal. Bedoel je met een informatie-eenheid wat in mijn voorbeeld een cluster is en in het binaire systeem een bit? En wat bedoel je met bandbreedte?

Ik heb toch duidelijk aangetoond dat er een exponentieel verband bestaat tussen de clustergrootte en de opslagruimte?

Of je nu N losse bits opslaat of verstuurt, of één cluster van N bits: het aantal mogelijke verschillende waarden die je kunt verzenden blijft 2N.

Mmm, daar zit wat in. Toch ben ik niet helemaal overtuigd. Je zegt:

In het geval van losse bits komt er niet één mogelijkheid bij per bit die je toevoegt, het aantal mogelijkheden verdubbelt.

Dit klopt. Echter; het is niet zo dat een computer z’n geheugencapaciteit verdubbelt als er 1 bitje bij komt. Hoe komt dat? Volgens mij heeft het er mee te maken dat het geheugen van een computer niet bestaat uit 1 ononderbroken groot getal.

Rogier schreef:Maar het aantal verschillende waarden dat een informatie-eenheid kan aannemen, komt niet overeen met de opslagruimte of bandbreedte die je nodig hebt om die eenheid op te slaan of te verzenden.

Dit snap ik niet helemaal. Bedoel je met een informatie-eenheid wat in mijn voorbeeld een cluster is en in het binaire systeem een bit?

Jep.

Laten we het voor het gemak op cluster houden, in het binaire systeem werken we dus met 'clusters' van 1 bit.

En wat bedoel je met bandbreedte?

Een soortgelijke maatstaf als opslagruimte, maar dan voor verzending. Bijvoorbeeld een kabel heeft een bepaalde maximale bandbreedte (signaaldoorvoer per seconde), de vraag is nu of je effectief meer data kunt verzenden door clusters van meer bits te verzenden in plaats van allemaal losse bitjes (en het antwoord is nee).

Ik heb toch duidelijk aangetoond dat er een exponentieel verband bestaat tussen de clustergrootte en de opslagruimte?

Nee, er is een exponentieel verband tussen de clustergrootte en het aantal mogelijkheden dat je in één cluster kwijt kunt.

Het verband tussen clustergrootte en opslagruimte is lineair.

Het verband tussen opslagruimte en het aantal mogelijkheden wat je in die opslagruimte kwijt kunt, is uiteraard ook exponentieel.

Of je nu N losse bits opslaat of verstuurt, of één cluster van N bits: het aantal mogelijke verschillende waarden die je kunt verzenden blijft 2^N.

Mmm, daar zit wat in. Toch ben ik niet helemaal overtuigd. Je zegt:

In het geval van losse bits komt er niet één mogelijkheid bij per bit die je toevoegt, het aantal mogelijkheden verdubbelt.

Dit klopt. Echter; het is niet zo dat een computer z’n geheugencapaciteit verdubbelt als er 1 bitje bij komt. Hoe komt dat? Volgens mij heeft het er mee te maken dat het geheugen van een computer niet bestaat uit 1 ononderbroken groot getal.

Het maakt niet uit of je het geheugen van een computer als 1 groot getal beschouwt of als veel kleintjes (het is ook geen van beide strikt goed of fout).

Net als bij het verzenden in clusters i.p.v. individuele bits is er helemaal geen verschil. Dat onderscheid maak je zelf, en is puur denkbeeldig. Of je iedere bit in een apart hokje zet, of steeds 4 bitjes bij elkaar doet in 1 hokje neemt en dat een cluster noemt, maakt geen enkel verschil.

Zie ook de verbanden hierboven, je moet goed het verschil in de gaten houden tussen:

- de grootte van de clusters waar je mee werkt

- hoeveel opslagruimte zo'n cluster inneemt

- hoeveel clusters je in totaal tot je beschikking hebt in je opslagruimte

- de hoeveelheid mogelijke verschillende waarden die je in een cluster (of in de totale opslagruimte) kwijt kunt

Opslagruimte tel je op, mogelijkheden vermenigvuldig je.

In één kilobyte geheugen kun je 8192 bits kwijt, per bit kun je 2 mogelijkheden kwijt, dus in totaal 2⁸¹⁹² verschillende mogelijkheden.

Door hier nu mee te werken alsof het 2048 clusters van ieder 4 bits zijn, kun je per cluster 16 mogelijkheden kwijt, dus in totaal 16²⁰⁴⁸ mogelijkheden, en dat is precies hetzelfde.

Opslagruimte tel je op, mogelijkheden vermenigvuldig je.

Aha, dus daar maak ik een denkfout. Bedankt.

Ik heb een mp3 file gezipt en ik behaalde nog een winst van 2%.

Een file van 100.000 bytes bestaande uit 0-255 random getallen kon de zip niet kleiner maken.

(wel groter door de data voor filename etc.)

Bij een driehoeksgolf van 0-255-0-255 etc in stapjes van 1 kon de zip de file van 100.000 inkorten tot maar 2000 bytes zoiets.

Faktor 50.

Dit is de momentele 'top' van de lossless compressie (hier kan je zien dat ZIP echt niet de top is):

http://www.maximumcompression.com/

Betere (lossy) video compressie dan MPEG4, zijnde xvid e.d., moet je voorlopig niet verwachten, de vooruitgang is bijna tot stilstand gekomen.

Voor jpg (dct-based) is nu jpg2000 (wavelet based) gekomen, de plaatjes zien er voor zeer hoge compressie dan iets beter uit dan jpg, maar het verschil is verwaarloosbaar (vind ik, bij zeer hoge compressie zijn beide formaten 'lelijk').

Door toename van opslag capaciteit, sneller internet, is compressie minder een issue geworden. Het belangrijkste is nu de standaard/uitwisselbaarheid, zodat iedereen dezelfde methodes gebruikt op het internet en in apparatuur. Daarom wordt ZIP nog steeds gebruikt, terwijl het allang niet meer de beste methode is. Hetzelfde geldt voor JPG.

Maar je weet nooit, maar zonder dat je weet hoe jpg, zip, of mpeg werkt verwacht ik niet dat je zomaar een uitvinding doet.

Maar je weet nooit, maar zonder dat je weet hoe jpg, zip, of mpeg werkt verwacht ik niet dat je zomaar een uitvinding doet.

Of misschien juist wel. Aangezien deze manieren van compressie tot stilstand komen, is het misschien verfrissend om er op een totaal andere manier tegenaan te kijken.

Een frisse kijk is natuurlijk altijd goed! Het is natuurlijk goed om vrij te zijn van de vast geroestte denkpatronen, maar enig inzicht in datacompressie kan volgens mij geen kwaad.

Je moet op z'n minst weten wat bits en zo voorstellen.

Maar het kan natuurlijk altijd zo zijn dat iemand met een fundamentele verandering komt.

voor de liefhebbers :

http://inls.ucsd.edu/~fisher/Fractals/

Laten we de topic houden op data compressie en niet op data reduktie door weglaten van zaken.

Sommige pictures op internet is niet om aan te zien door de vieze verkleuring van het wit rondom de letters.

Een ruisfilter is een datareduktie maar is nodig om oude films op te lappen.

Mogelijkheden:

De helderheidsinformatie kan de kleurinformatie nog bewerken zodat deze gelijkwaardiger wordt waardoor deze nog optimaler wordt.

Ook kan men data-matrixen gebruiken voor bepaalde zaken.

Deze data-matrixen kan men tijdens de film setup inladen in het geheugen.

Rand schreef:Kortom er zijn nog weinig feiten op tafel , ook in dit forum weinig feiten dus.

1) Romke Jan Bernard Sloot was TV-reparateur, analoog WAS zijn ervaring. hij heeft zich later verdiept (zelfstandig) in digitale technieken.

2) alle berekeningen die ik hier en op andere forums zie zijn gebaseerd op de "oude" technieken.

3) Zijn uitvinding had wel degelijk meer nodig dan alleen de keycard van 64kb, in zijn "kastje" zat geheugen ingebouwd

4) Zijn eigen claim was een verbetering van 8x tov de "oude" technieken"

We moeten leren feiten en speculaties te scheiden en alleen met feiten verder te gaan. ALs we dat massaal zouden doen dan reproduceren we snel "zijn" uitvinding, er is genoeg technisch vernuft onder ons.

Kijk nog eens naar een feit: www.Davoc.com, is recentelijk ge-update.

Rand(t)

Rand(t),

Mag ik vragen waar je te weten bent gekomen dat er geheugen was ingebouwd in het "kastje" van Jan Sloot. Ben je er zeker van? En zo ja, weet je daar iets meer over?

Volgens mij had Jan nogal grootheidswaanzin...

En dat er een boek van Robert Ludlum in zijn kluis bij de bank is gevonden naast wat nutteloze actrooien is daar volgens mij een bewijs van...

Ik heb destijds het boek ook gelezen...

is er inmiddels nog wat naar boven geborreld hier?