De Broncode

[EvilBro]

De broncode in een notendop (geen echte notendop natuurlijk... een spreekwoordelijke notendop):

[Rogier]

Ik bedoel hier dus niet mee dat de data overdracht met licht gebeurt zoals in de bronlink vermelde technologie. maar dat aan het proces ook een laser deelneemt.

Reeds in 2002

Bron

Oh, interessant, die techniek kende ik niet. Maar zoals je zelf ook al stelt blijft dat evengoed een puur magnetisch proces (zowel de opslag als het lezen/wegschrijven), de laser heeft hier verder niets met optisch te maken. En in het verlengde daarvan denk ik niet dat deze techniek de verschuiving naar SSD zal omkeren.

Hoe dan ook, ik denk dat we kunnen stellen dat dat in ieder geval niets van doen heeft met Jan Sloot's vermeende Broncode, waarin juist "het binair denken overstijgd moest worden" en sprake was van "een speciale manier van coderen", als we de aanhangers mogen geloven...

[mcs51mc]

Heb je weleens een harde schijf open gemaakt?

Zo ja vertel mij dan eens waar die laser diode voor dient die over de schijf heen loopt tijdens het lezen en schrijven.

Open anders even deze link en scroll de pagina naar beneden en lees aldaar de volgende text:

En 8 jaar later wordt dit nog steeds niet toegepast of toch? Eergisteren nog wat HDD open geprutst, weliswaar van voor 2002.

De mini disc van Sony, was dat geen optische schijf? Ik dacht van wel, en waar is de mini disc gebleven? Inderdaad zo snel opgekomen en nog véél sneller afgevoerd

Ik denk dat Evilbro nog dichtst bij de juiste uitleg zit ](*,)

[klazon]

De mini disc van Sony, was dat geen optische schijf?

Nee, de minidisc is een magnetische schijf. Maar bij het beschrijven wordt de schrijfplek verhit door een laser om de magnetisering te vergemakkelijken. Zou best kunnen dat deze truc ook in HDD's wordt toegepast.

[mcs51mc]

Nee, de minidisc is een magnetische schijf. Maar bij het beschrijven wordt de schrijfplek verhit door een laser om de magnetisering te vergemakkelijken. Zou best kunnen dat deze truc ook in HDD's wordt toegepast.

Zou inderdaad best wel dezelfde technologie kunnen zijn. Beiden hebben het althans over warmte

... ...demonstreert met succes Heat-Assisted Magnetic Recording. HAMR slaat magnetisch op met behulp van laser-thermische bijstand en poogt uiteindelijk de gebiedsdichtheid te verhogen met meer dan 100 keer de 2002 niveaus.

[317070]

Ik bedoel hier dus niet mee dat de data overdracht met licht gebeurt zoals in de bronlink vermelde technologie. maar dat aan het proces ook een laser deelneemt.

Reeds in 2002

Quote

2002: Een van de vele verwezenlijkingen in de 2002 technologie; Seagate demonstreert met succes Heat-Assisted Magnetic Recording. HAMR slaat magnetisch op met behulp van laser-thermische bijstand en poogt uiteindelijk de gebiedsdichtheid te verhogen met meer dan 100 keer de 2002 niveaus.



Bron

Toegegeven, de laatste harde schijf die ik openhaalde dateerde uit de tijd dat 10MB spitstechnologie was, en het is inderdaad mogelijk dat er lasers zitten in harde schijven, maar deze worden volgens mij niet gebruikt voor de toepassingen die je hier aanhaalt. Je bron maakt overigens nog steeds geen gewag van commerciele toepassingen van lasers in harde schijven, enkel academische resultaten.

Dus ging ik zelf even op onderzoek uit naar Heat-Assisted Magnetic Recording en vond dit:

Which of these technologies will eventually replace present-day magnetic recording is anyone’s guess, Schlesinger says. ”If HAMR is going to have a chance in the marketplace, then in five years I would expect to see some commercial system out there.”

Dit komt uit een artikel van de IEEE, toch wel een (misschien zelfs de) autoriteit op gebied van electrical engineering. Het is overigens geschreven in maart 2009, dus ik geloof niet dat HAMR al commercieel beschikbaar is. Meer zelfs, het is nog niet eens zeker of de technologie het gaat halen.

Als je dus nog dingen zou vinden die voor lasers in harde schijven zorgen, laat het zeker weten, maar liefst met een betrouwbare bron, die zwart-op-wit verdedigt wat je in je bericht schrijft, en niet er vaag mee te maken heeft.

Dit bericht zeker niet persoonlijk nemen, maar ik merkte dat er al mensen weg mee waren. HAMR wordt dus nog (lang) niet gebruikt in commerciele modellen. De link met minidisc lijkt me dus bijzonder speculatief dezelfde technologie lijkt me al helemaal onwaarschijnlijk...

[holland]

Dr zijn meerdere methodes om dm van lasers de data dichtheid te vergroten. De in mijn laatste en voorlaatste bron zijn twee verschillende technieken.

Trouwens een magneto-optical disk is niet iets nieuws, Alleen heeft deze techniek het niet gehaalt, en wordt noch maar weinig toegepast.

bron

Ik ben meestal een beetje te vlug met mijn gevolgtrekking te maken en heb dus twee technieken door elkaar gehaald net als 317070 nu ook doet. Geeft niks hoor ik leer van mijn fouten.

In ieder geval zijn de nieuwe generatie harde schijven uitgerust met een laser maar dan volgens het hamr principe, en dat is iets anders als de Nijmeegse academie heeft aangetoond.

Maar we wijken van het onderwerp af.

Feit blijft dat met de middelen die tegenwoordig beschikbaar zijn het onmogelijk is om op een opslag media 16 fimls te plaatsen, welk media evenveel leespunten heeft als voor 128Kb normaal nodig zou zijn.

[Bartjes]

Het aantal mogelijke films is natuurlijk astronomisch groot wanneer je inderdaad alle mogelijke opeenvolgingen van alle mogelijke beeldjes in ogenschouw neemt.

Maar veel van die "films" zijn voor het menselijk oog niet te onderscheiden. De gebruikelijke vormen van datacompressie maken van die speelruimte gebruik.

Echter - de overgrote meerderheid van die als verschillend te onderscheiden "films" is rommel die door een toeschouwer niet als een film in de eigenlijke zin van het woord zou worden beschouwd. Daar zit in principe nog veel speelruimte voor verdere datacompressie. Je zou een wiskundige manier moeten vinden om alle echte films (dus films in de eigenlijke zin van het woord) te kunnen genereren. Het absolute minimum aan benodigde geheugenruimte wordt dan bepaald door het maximale aantal als verschillend ervaren eigenlijke films.

Ik las ergens iets over fractals, in een dergelijke richting zou je het moeten zoeken. Overigens heb ik niet dit hele topic doorgenomen, dus mogelijk is mijn voorstel al langs gekomen.

[mcs51mc]

dit:

Strange dat dit artikel niets zegt over Fujitsu maar enkel over Seagate.

Bij Fujitsu waren ze in 2006 al (bijna) overtuigd dat dit de toekomst was: lees hier , alhoewel hun besluit toch wel wat vragen open laat

Iemand zin om vb deze 2TB HDD open te prutsen om te zien of HAMR nu daadwerkelijk gebruikt wordt in actuele HDD's??

Want aan 80GB/2.5inch disc, zoals er in dat Fujitsu document staat, heb je 25 disks nodig voor dergelijke HDD en dat zit er zeer zeker niet in.

Hier zien ze bij Fujitsu de toekomst van HAMR al rooskleuriger uit

[317070]

Het absolute minimum aan benodigde geheugenruimte wordt dan bepaald door het maximale aantal als verschillend ervaren eigenlijke films.

Er is dan wel nog een 2e factor in de discusse, namelijk dat het algoritme om die codering te decoderen net zo groot wordt als al de films samen

M.a.w. zo'n codering is een schijncodering, de benodigde opslagruimte blijft even groot, maar nu kruipt bijna alle ruimte in je decoderingsalgrotime. Dat het een ondergrens is klopt wel.

[Bartjes]

Er is dan wel nog een 2e factor in de discusse, namelijk dat het algoritme om die codering te decoderen net zo groot wordt als al de films samen

M.a.w. zo'n codering is een schijncodering, de benodigde opslagruimte blijft even groot, maar nu kruipt bijna alle ruimte in je decoderingsalgrotime. Dat het een ondergrens is klopt wel.

Mijn voorstel betreft een verschuiving van het probleem, daar heb je gelijk in. Maar ik zie niet zo gauw dat er zo - per definitie - geen winst meer te behalen is. Het is niet de bedoeling alle mogelijke echte films ergens op te slaan, en die dan aan te roepen. Dat zou inderdaad een schijnoplossing zijn. Wat je wel zou moeten doen is de steeds terugkerende patronen in echte films rubriceren, en die aanroepen. De daarna nog ontbrekende gegevens kunnen op de gebruikelijke manier worden ingekleurd.

Hoe dit in de praktijk zou moeten, weet ik zelf ook niet.

[317070]

Wat je wel zou moeten doen is de steeds terugkerende patronen in echte films rubriceren, en die aanroepen. De daarna nog ontbrekende gegevens kunnen op de gebruikelijke manier worden ingekleurd.

Hoe dit in de praktijk zou moeten, weet ik zelf ook niet.

Daar heb je gelijk in, er is inderdaad nog (veel) verbetering mogelijk, maar praktisch is het niet zo interessant. Een gewone mens bekijkt iets van een duizendtal films op 1 dvd-speler. (oke, een echte cinefiel) Als je die dvd-speler dan moet uitrusten om alle patronen van miljarden films op te slaan, dan ben je niet echt efficient bezig. Je kunt er zoveel aan verbeteren als je wil, maar je grootte-orde van alle (mogelijke) zinvolle films is zo ongeloofelijk groot, dat zo'n algoritme nog niet vast te leggen is.

Er zijn wel al dingen die die richting uitgaan, zoals flash filmpjes waarvan de lettertypes al op je PC opgeslagen zitten, of ingame videos die je dan kunt afspelen binnen het spelletje op je eigen PC. (die laatste gaan wel gemakkelijk onder de MB voor enkele minuten)

Maar er is een reden dat films als Shrek niet afgespeeld worden door alle frames 1 voor 1 te renderen. Dit zou een zeer sterke compressie betekenen, anderzijds hebben de mainframes bij pixar al enkele mintuen nodig om 1 enkele frame te renderen. Ze moeten soms een uur rekenen voor 1 seconde film. Dus je ziet: de compressie kan er zeer sterk zijn, maar het algoritme wordt dan zo zwaar dat het niet meer praktisch haalbaar is.

Dus het algoritme moet passen op de gegeven ruimte, moet snel genoeg kunnen rekenen en de extra data voor de specifieke film moet zo klein mogelijk zijn om praktisch te kunnen zijn.

[Bartjes]

Daar heb je gelijk in, er is inderdaad nog (veel) verbetering mogelijk, maar praktisch is het niet zo interessant. Een gewone mens bekijkt iets van een duizendtal films op 1 dvd-speler. (oke, een echte cinefiel) Als je die dvd-speler dan moet uitrusten om alle patronen van miljarden films op te slaan, dan ben je niet echt efficient bezig. Je kunt er zoveel aan verbeteren als je wil, maar je grootte-orde van alle (mogelijke) zinvolle films is zo ongeloofelijk groot, dat zo'n algoritme nog niet vast te leggen is.

Er zijn wel al dingen die die richting uitgaan, zoals flash filmpjes waarvan de lettertypes al op je PC opgeslagen zitten, of ingame videos die je dan kunt afspelen binnen het spelletje op je eigen PC. (die laatste gaan wel gemakkelijk onder de MB voor enkele minuten)

Maar er is een reden dat films als Shrek niet afgespeeld worden door alle frames 1 voor 1 te renderen. Dit zou een zeer sterke compressie betekenen, anderzijds hebben de mainframes bij pixar al enkele mintuen nodig om 1 enkele frame te renderen. Ze moeten soms een uur rekenen voor 1 seconde film. Dus je ziet: de compressie kan er zeer sterk zijn, maar het algoritme wordt dan zo zwaar dat het niet meer praktisch haalbaar is.

Dus het algoritme moet passen op de gegeven ruimte, moet snel genoeg kunnen rekenen en de extra data voor de specifieke film moet zo klein mogelijk zijn om praktisch te kunnen zijn.

Van de praktische aspecten heb ik geen kaas gegeten. Het leek mij alleen wel leuk om te bedenken hoe je theoretisch gezien onder de gebruikelijke datacompressie-grens zou kunnen duiken. Zou het iets zijn om steeds alleen de veranderingen t.o.v. van een aantal karakteristieke shots en acties (gezichten, locaties, handelingen, etc.) te coderen - of wordt dit al gedaan?

[317070]

Van de praktische aspecten heb ik geen kaas gegeten. Het leek mij alleen wel leuk om te bedenken hoe je theoretisch gezien onder de gebruikelijke datacompressie-grens zou kunnen duiken. Zou het iets zijn om steeds alleen de veranderingen t.o.v. van een aantal karakteristieke shots en acties (gezichten, locaties, handelingen, etc.) te coderen - of wordt dit al gedaan?

Wel, van ieder afzonderlijke shot zijn er zogenaamde I-beelden. Dit zijn beelden die feitelijk als foto opgeslagen zijn. Na een I-beeld heb je een hele hoop P-beelden. Dit zijn beelden die enkel afhangen van beelden die ervoor gekomen zijn. Tussen die beelden zijn er ook nog de B-beelden, dat zijn de beelden die afhangen van beelden die zowel ervoor als erna komen.

Ieder beeld wordt opgesplitst in macroblokken, en voor die macroblokken wordt dan in andere beelden gezocht naar een stukje beeld die er goed op lijkt. (aangezien het beeld in 5 frames meestal niet veel verandert, lukt dat heel goed) Dan sla je op waar je je referentieblok kunt vinden, en het verschil tussen jouw blok en het referentieblok. Dit verschil kan in de praktijk zeer gemakkelijk gecomprimeerd worden in het frequentiedomein door linear predictive coding of door de hoge frequenties uit het beeld weg te laten. In de praktijk zien we daar maar weinig/geen artefacten van.

Dit alles is afgestemd om goed te kunnen de film comprimeren, maar ook om het decoderen niet te zwaar te maken. Let er op dat je ieder beeld waaruit je later nog stukken als referentie kunnen gebruikt worden opgeslagen moeten blijven in het geheugen van de decoder. Meer zelfs, voor B-beelden moeten al beelden vooruit berekend worden. Meestal beperkt men de zoekruimte dan ook tot enkele beelden, bv enkel de I-beelden.

Dit is grotendeels de manier waarop de MPEG codecs werken. Let ook dat het codeer algoritme hier heel zwaar is. Om voor ieder macroblok op zoek te gaan in 30 beelden naar het beste stukje beeld als referentie is heel rekenintensief. Voor 30 beelden van 1 megapixel heb je dan namelijk al ongeveer 30 miljoen stukjes die als referentie kunnen dienen. Grote compressie is dus meestal ook niet geschikt om uit te voeren op bv. camera's of gsm's.

Je merkt, in het klein word je idee al gebruikt. Maar videocodecs zijn iets die zich meestal op de rand van het mogelijke zitten. Ieder beeld vereist veel geheugen, en iedere vorm van compressie en decompressie loopt al snel tegen rekentechnische grenzen aan. Vrijwel nooit is de compressie zelf de grens, meestal\altijd zijn het de rekencapaciteiten aan beide kanten voor het coderen en decoderen die de begrenzing vormen.

[Bartjes]

Je merkt, in het klein word je idee al gebruikt. Maar videocodecs zijn iets die zich meestal op de rand van het mogelijke zitten. Ieder beeld vereist veel geheugen, en iedere vorm van compressie en decompressie loopt al snel tegen rekentechnische grenzen aan. Vrijwel nooit is de compressie zelf de grens, meestal\altijd zijn het de rekencapaciteiten aan beide kanten voor het coderen en decoderen die de begrenzing vormen.

In theorie is hier dus nog veel mogelijk, wat praktisch vooralsnog onhaalbaar is. Grappig!