[opslag] 6 bits ipv 8 gebruiken bij optische media

[Verwijderd]

Het idee voor een andere/efficiëntere manier van gegevens opslaan kwam in mij op tijdens een les biologie. Bij deze les kregen we uitleg over DNA en hoe dit uitgelezen word. Meteen dacht ik aan de evolutietheorie. Hierbij overleven (over het algemeen) de best functionerende wezens en om goed te functioneren is het wel fijn om een goede basis te hebben. daarom dacht ik gelijk aan het gebruik van AGTC zoals in DNA voor de opslag van gegevens. (niet iedereen zal de hierboven beschreven denkwijze snappen maar het gaat om het resultaat)

Om eiwitten te maken word het DNA afgelezen in stukken van 3 base (als ik het goed zeg, heb ff biologie boek niet bij de hand). met deze 4 verschillende base, AGTC, die per 3 uitgelezen worden zijn er 64 combinaties te maken (4x4x4). Op deze manier hoeven er maar 3 ipv 8 bits gebruikt te worden, echter is er een probleem, je kan alleen putjes en gaten maken. Hier dacht ik aan een dual layer schijf. door de eerste layer en de tweede te combineren kan je 4 combinaties van puntjes en putjes maken.



Hier hebben we dus DNA op een dual layer schijf. Als we nu 3 letters achter elkaar zetten kunnen we de bijbehorende letters/cijfers plaatsen op dezelfde manier als je opzoekt wel eiwit er bijv bij ATG hoort.



eerste letter zoek je links op, tweede letter zoek je boven op en de derde letter rechts zodat je dan in het vakje met die combinatie uitkomt (welke dan correspondeert met een bepaald(e) letter/cijfer). op deze manier is het mogelijk om de opslagcapaciteit van een dual layer schijf met 33% uit te breiden. hieronder een voorbeeld.



Hier zie je boven de traditionele manier van opslaan wat 8 delen in beslag neemt en onder zie je de manier die ik zojuist beschreven heb waar je maar 3 delen nodig hebt. echter, omdat het dual layer is kan op de traditionele manier 6 tekens opgeslagen worden en op mijn manier kunnen er 8 opgeslagen worden. Hiermee kan de capaciteit van een dual layer dvd van 9 naar 12 gig uitgebreid worden.

Aangezien ik géén verstand heb van programmeren en ik niet weet hoeveel mogelijkheden er exact zijn voor de originele manier van opslaan (kon het zo snel niet vinden) weet ik niet of deze methode wel toereikend genoeg is om data op te slaan (als er bijv 100 verschillende combinaties gebruikt worden voor het opslaan van data is mijn manier niet toereikend genoeg).

aangezien jullie meer weten van programmeren en sommige wellicht van opslaan is mijn vraag of jullie mijn theorie kunnen bevestigen en dat het inderdaad een effectievere manier van opslaan is of dat ik onzin praat.

Nu het aflezen.
Om de data op deze manier af te lezen heb ik twee dingen bedacht. Ook hier weer, ik weet niet of het kan of dat ik onzin praat.

manier 1:
Bij deze manier leest de dvd speler hetzelfde stuk twee keer, een keer de bovenste layer en een keer de onderste layer. Hierbij moet in de tussentijd de data opgeslagen worden en daarna gecombineerd tot een deel. hierdoor word de lees snelheid echter gehalveerd (moet twee keer over een stuk heen) maar dit geld alleen in vergelijking tot een single layer schijf. iedere andere dual layer schijf moet hij zowiezo twee keer overheen gaan (toch?). voordeel van deze manier is dat men geen nieuwe DVD lezer hoeft aan te schaffen, een simpele software update is genoeg om deze manier van lezen mogelijk te maken.

manier 2:
Deze manier was de eerste die in me opkwam en misschien wel de meest omslachtige. Hierbij worden twee lasers gebruikt, een leest de bovenste layer en de andere leest de onderste. hierbij blijf je dezelfde lees snelheid houden als je bij de normale manier van lezen hebt. nadeel is men een nieuwe dvd speler moet kopen.

Dat was mijn idee in een notendop. dus zoals ik al vroeg, is dit mogelijk of heb ik gewoon grote fouten gemaakt en is deze manier van opslaan echt totale onzin?

als het verkeerd geplaatst is, vertel het maar en verplaats hem waar hij wel hoort, ik had namelijk geen idee waar dit moest

[farlane]

Hoeveel mogelijkheden kun je maken met jouw 6 bits en hoeveel kun je er maken met 'onze' acht 8 ?

Applaus voor je startpost tho

Btw:

2^6 = 64
2^8 = 256

[Verwijderd]

hmmm, das waar, worden dan ook alle 256 mogelijkheden gebruikt of heeft een pc genoeg aan 64 mogelijkheden. Denk zelf eigenlijk niet omdat we anders zowiezo met minder bits gerekend hadden.

jammer als er nog een 4e rij toegevoegd word komen we weer gewoon op 8 bits uit dus heb je geen voordeel.

probleem is dat in programeertaal (wat ik er van zie) nogal veel met tekens gewerkt word zoals :;'[]{ etc etc, aan alleen de letters en cijfers ben je al 36 mogelijkheden kwijt en dan heb je nog niet eens hoofdletters.

[ Voor 26% gewijzigd door Verwijderd op 13-03-2008 21:00 ]

[Soultaker]

Wat je feitelijk voorstelt in je topic start is dat je gevegens efficienter kunt coderen als je weet dat bepaalde karakters niet voorkomen, en als je aannamen kunt doen over de volgorde waarin karakaters achter elkaar geplaatst worden.

Als idee niet verkeerd; Google maar eens op "entropy coding" of "prediction by partial matching" en dan zie je dat deze concepten de basis zijn losless compressiealgoritmen. (Als je dit interessant vind, is het volgende artikel wel aardig: Arithmetic Coding + Statistical Modeling = Data Compression, maar ik weet niet of het goed te volgen is voor niet-programmeurs.)

[ Voor 23% gewijzigd door Soultaker op 13-03-2008 21:47 ]

[Verwijderd]

Het was ook onmogelijk dat er nog nooit iemand eerder op het idee was gekomen

maar dit is dus eigenlijk hoe compressieprogramma's zo ongeveer werken? Overbodige karakters wegmoffelen?

[.oisyn]

Oa. En een frequentie-analyse doen op de gebruikte karakters en zorgen dat het meest gebruikte karakter het minste ruimte inneemt (huffman coding), of bijvoorbeeld heel veel dezelfde karakters achter elkaar coderen als N x dat karakter (run-length encoding)

[Orphix]

Ik deel je enthousiasme uit je startpost! Zo had ik laatst ook, dacht ik, een briljant idee over hoe je informatie efficient kon opslaan. Het was een hersenspinsel, maar het had iets te maken met bits hergebruiken door een verzameling bits als een 3 dimensionale matrix te benaderen. Je raadt al, ik kwam op hetzelfde probleem uit als jij, je doet (al dan niet onbewust) aannames over de informatie die je gaat opslaan. Of je gebruikt ongemerkt externe informatie bij het encoderen, en die moet je natuurlijk wel meetellen in het geheel. Zie ook het Pigeonhole principe.

Maargoed dit houdt ons brein fris en fruitig

[ Voor 3% gewijzigd door Orphix op 13-03-2008 23:58 ]

[Osiris]

Wat jij wil bestaat allang: analoog

Het 'idee' van digitaal is juist het gebruik van eentjes en nulletjes, niets meer en niets minder. Zodra jij opeens wil gaan werken met bits die i.p.v. twee waardes vier waardes aan kan nemen, tja, natuurlijk krijg je dan een hogere datadichtheid. Maar dan is 't niet meer digitaal IMO.

Hmm, wacht, je ATCG's e.d. staan alsnog binair op de schijf, dus ik lul poep. Ga maar weer door met over encryptie praten mensjes

[ Voor 17% gewijzigd door Osiris op 14-03-2008 00:16 ]

[roy-t]

Is het niet heel erg langzaam uit te lezen dan zo'n codering?

Ik neem aan dat een lens zich dan voor elke 'byte' 2x moet scherp stellen, 1x op de boven en 1x op de onderlaag van de DL schijf.

Natuurlijk kun je ook om en om doen. (positie1 is een A of G, positie 2 een T of C)

Wel leuk bedacht trouwens! :-) nu nog een systeem waarin een bit 4 posities heeft uitvinden, dit moet toch mogenlijk zijn lijkt me. En lijkt me een logische stap voordat we naar quantum computing gaan. (Wat toch nog steeds erg onvoorspelbaar blijft.

[Toolskyn]

Sowieso worden bij dual-layer schijfjes de beide lagen niet tegelijk gelezen, dus dat werkt sowieso niet. Daarbij worden bits niet zomaar achter elkaar gezet op dit soort media (Hard Disks, CDs, DVDs etc etc), maar wordt er gebruik gemaakt van allerlei interleaving technieken. Dus de data zoals jij die uitleest staat helemaal niet in die volgorde op je schijfje.

Je moet je in ieder geval niet voorstellen dat bytes opgeslagen zijn op de manier zoals in de topicstart is aangegeven.

[wackmaniac]

Wackmaniac krijgt flashbacks over De Broncode

Dit is namelijk een beetje de wijze waarop Jan Sloot had bedacht (vermeend) om gegevens op te slaan. Hij had het erover dat hij geen 1-en en 0-en gebruikte, maar meerdere opties. Een beetje het idee dus van een bit die 4 mogelijke waardes heeft ipv 2.

[voodooless]

Je hebt gewoon een leuke manier bedacht om DNA efficiënt op te slaan Maar je kan het natuurlijk nog veel makkelijker beredeneren:

Je hebt 64 combinaties dus gewoon 6 bits nodig om 1 DNA base op te slaan. Die kun je gewoon achter elkaar zetten, en je hebt daar ook geen ingewikkelde dual layer DVD voor nodig . Alles wat dan nog rest is (bijvoorbeeld) een lookuptable om er weer letters van te maken

[unclero]

wackmaniac schreef op vrijdag 14 maart 2008 @ 08:34:
Wackmaniac krijgt flashbacks over De Broncode

Dit is namelijk een beetje de wijze waarop Jan Sloot had bedacht (vermeend) om gegevens op te slaan. Hij had het erover dat hij geen 1-en en 0-en gebruikte, maar meerdere opties. Een beetje het idee dus van een bit die 4 mogelijke waardes heeft ipv 2.

Ik had het boek een beetje door zitten bladeren, en ik dacht juist dat hij een geniaal collision-resistant hashing-algoritme had verzonnen en een manier om die one-way-compression een two-way te maken.

[wackmaniac]

unclero schreef op vrijdag 14 maart 2008 @ 09:55:
[...]


Ik had het boek een beetje door zitten bladeren, en ik dacht juist dat hij een geniaal collision-resistant hashing-algoritme had verzonnen en een manier om die one-way-compression een two-way te maken.

Ik meende dat hij nogal vaak riep dat er niet moet worden gedacht in 1-en en 0-en, maar ja, vragen zal wat lastig worden

[.oisyn]

Wat Jan Sloot had bedacht was het creëren van een generieke database aan informatie, die gebruikt kon worden om elke film mee te herconstrueren gegeven een bepaalde sleutel. Hij claimde bovendien dat een database van minder dan 400MB en een sleutel van 1kB genoeg was. Onzin natuurlijk, want het aantal films dat je kunt bedenken is oneindig, terwijl je met een sleutel van 1kB slechts een selectie kunt maken van 2⁸¹⁹² films.

Het is een beetje als dat verhaal van die alien die naar onze aarde komt en besluit om de inhoud van al onze boeken weer mee terug te nemen naar zijn eigen planeet. Het enig waar hij (naast z'n ruimteschip natuurlijk) over beschikt is een stok. Dus hij digitaliseerd alle Aardse boeken, zet dat om in een hele lange (maar eindige) bitstring. Daar plaatst hij een '0.' voor zodat de bitstring een getal voorstelt tussen 0 en 1. Vervolgens zet hij een simpel streepje op z'n stok op de juiste lengte. Bij thuiskomst hoeft hij alleen maar de positie van het streepje op te meten en hij kan alle informatie weer terughalen.

[/\/\|)]

.oisyn schreef op vrijdag 14 maart 2008 @ 10:50:
Wat Jan Sloot had bedacht was het creëren van een generieke database aan informatie, die gebruikt kon worden om elke film mee te herconstrueren gegeven een bepaalde sleutel. Hij claimde bovendien dat een database van minder dan 400MB en een sleutel van 1kB genoeg was. Onzin natuurlijk, want het aantal films dat je kunt bedenken is oneindig, terwijl je met een sleutel van 1kB slechts een selectie kunt maken van 2⁸¹⁹² films.

Het is een beetje als dat verhaal van die alien die naar onze aarde komt en besluit om de inhoud van al onze boeken weer mee terug te nemen naar zijn eigen planeet. Het enig waar hij (naast z'n ruimteschip natuurlijk) over beschikt is een stok. Dus hij digitaliseerd alle Aardse boeken, zet dat om in een hele lange (maar eindige) bitstring. Daar plaatst hij een '0.' voor zodat de bitstring een getal voorstelt tussen 0 en 1. Vervolgens zet hij een simpel streepje op z'n stok op de juiste lengte. Bij thuiskomst hoeft hij alleen maar de positie van het streepje op te meten en hij kan alle informatie weer terughalen.

Iederen die bekend is met het pigeonhole principle wist natuurlijk gelijk dat Jan Sloot's uitvinding gewoon niet kon werken zoals hij beweerde. Merkwaardig dat Roel Pieper er aanvankelijk in geloofde.

[beany]

.oisyn schreef op vrijdag 14 maart 2008 @ 10:50:
Onzin natuurlijk, want het aantal films dat je kunt bedenken is oneindig, terwijl je met een sleutel van 1kB slechts een selectie kunt maken van 2⁸¹⁹² films.

Is het aantal films echt oneindig? Elk frame van een film heeft een beperkt aantal mogelijkheden:

Een frame heeft een breedte, hoogte en per pixel een kleur(24 bits b.v.). Je kan dus het maximaal aantal verschillende mogelijkheden berekenen voor dat frame.

Dus dan kan je ook het totaal aantal mogelijke verschillende films berekenen(totaal aantal frames)

Het getal wat eruit komt is bizar groot, maar je kan het berekenen. Als je een frame generator programmeert die elke combinatie genereert, en je selecteert daar handmatig de bruikbare frames uit kan je in principe al de film maken die pas over 10 jaar door Holywood gemaakt word... alleen is het praktisch gezien niet te doen

[.oisyn]

beany schreef op vrijdag 14 maart 2008 @ 11:12:
Dus dan kan je ook het totaal aantal mogelijke verschillende films berekenen(totaal aantal frames)

Dan hebben de films die je kunt coderen een maximale lengte. Ik kan echter altijd een film bedenken die 1 frame langer is dan de langste film.

[/\/\|)]

.oisyn schreef op vrijdag 14 maart 2008 @ 11:41:
[...]

Dan hebben de films die je kunt coderen een maximale lengte. Ik kan echter altijd een film bedenken die 1 frame langer is dan de langste film.

Aftelbaar oneindig dus.

[Janoz]

Het aantal mogelijke films is wel degelijk oneindig. Zodra jij met een maximaal aantal aan komt zetten weet ik die weer te verdubbelen door alle mogelijkheden die jij hebt uit te breiden met 1 frame.

Het aantal mogelijke verschillende versies van een seconde film is daarentegen wel redelijk eindig (zolang je een discrete opslag methode gebruikt).

Maar goed, reken uberhaupt maar eens uit hoeveel verschillende mogelijke filmpjes van 1 seconden er mogelijk zijn met een 24bit pixel op 640x480 25fps. Dat kun je in verhouding met 2⁸¹⁹² best tot de categorie 'oneindig' rekenen...

[? ?]

Deze discussie komt toch telkens op hetzelfde neer?

Ofwel heb je veel opslagdata met weinig metadata
1 byte, met 256 mogelijkheden

Ofwel weinig opslagdata met veel metadata
zo kun je een ganse frame in een paar bytes stoppen, als je voor elke paar bytes weet waar de frame voor staat

wat .oisyn ook zegt: 0, voorzetten en je hebt met een streepje genoeg Maar dan moet je precisie natuurlijk enorm groot zijn, krijg je niet echt makkelijk voor elkaar.
in een zandkorrel zitten 78 000 000 000 000 000 000 atomen, dus als je alle atomen van die stok zou gebruiken in een volgorde en ze op volgorde kunt houden, zou je misschien wat wat kunnen stockeren. (het wiskundige laat ik aan iemand anders).

Verder kun je ook een bytestring als getal zien.
En dat beschrijven, eigenlijk vind ik dit wel een leuk idee, omdat je toch per operatie toch exponentiëel grotere getallen kun maken. 10^784546546545646545 vergt 21 bytes, terwijl de rekensom volluit veeeeeel bytes is Opnieuw: een rekenkundig bewijs zou ik wel willen zien

[Soultaker]

beany schreef op vrijdag 14 maart 2008 @ 11:12:
Is het aantal films echt oneindig? Elk frame van een film heeft een beperkt aantal mogelijkheden:

Flink off-topic natuurlijk, maar het idee van Jan Sloot werkt ook met flinke inperkingen van de mogelijke films niet.

Bijvoorbeeld: stel ik maak een film van een uur, die uit niets anders bestaat dan dat er elke seconde een andere hoofdletter op het scherm staat. Dat lijkt me duidelijk genoeg dat je dat zonder verlies moet kunnen coderen. Toch kun je daarmee 26³⁶⁰⁰ verschillende films maken en heb je dus ²log(26³⁶⁰⁰) bits = ~16Kb nodig om elke film uniek te coderen. Dat gaat met een kilobit (of een kilobyte) natuurlijk niet, en je ziet dat als je maar een paar kleine mogelijkheden toevoegt het aantal mogelijke films ontzettend snel stijgt.

[MSalters]

Het meest simpele tegenbewijs is dat je 2 1KB sleutels in 1 film kunt tonen. Dus 1 film bevat vervolgens twee films, etctetera.

[zeroxcool]

MSalters schreef op zaterdag 15 maart 2008 @ 12:36:
Het meest simpele tegenbewijs is dat je 2 1KB sleutels in 1 film kunt tonen. Dus 1 film bevat vervolgens twee films, etctetera.

die had ik nog niet gehoord ...