Interessantes Konzept der Datenspeicherung
uwe
- programmiertechnik
0 MatzeA0 Thoralf Knuth
Hallo zusammen
Bin gerade durch Zufall auf folgende englischsprachige Seite aufmerksam geworden:
Erstaunliche Resultate, wie ich finde.
Cheers
Uwe
Portland, OR
Servus,
so ganz steige ich noch nicht durch...
Ist es ein Grafik Bearbeitungsprogramm oder eine Datenkomprimierungstool??
Ich stehe mit dem was ich auf der Seite sehe und lese und Deiner Überschrift im zwiespalt.
Gruss Matze
Hi,
erstaunlich schnell das Teil.
Und es löscht mir nun schon zum zweiten Mal die User-Credentials...
Grüße
Tom
Hi Tom
Und es löscht mir nun schon zum zweiten Mal die User-Credentials...
Hmm, ich hab' jetzt drei der Demos ausprobiert, ohne dass ich negative Auswirkungen auf meinen (XP Pro) Rechner beobachten konnte. Kannst du mal genauer beschreiben, was du gemacht hast?
Cheers
Uwe
Portland, OR
Hi Matze
Ist es ein Grafik Bearbeitungsprogramm oder eine Datenkomprimierungstool??
Weder noch. Was die Leute dort beschreiben ist ein Verfahren, um massive Datenmengen in einer 64K grossen Datei unterzubringen. Und zwar nicht durch Kompression, sondern durch "Beschreibung" der Information (weiss nicht, wie ich es besser ausdruecken soll. Vom Prinzip wohl aehnlich wie SVG). Folge mal den einzelnen Links, dann wird alles etwas klarer. Ich war am Anfang genauso verwirrt wie du.
Cheers
Uwe
Portland, OR
Servus,
aha verstanden.
Werde ich mir morgen in aller ruhe mal ansehen.
Gruss Matze
Moin!
Weder noch. Was die Leute dort beschreiben ist ein Verfahren, um massive Datenmengen in einer 64K grossen Datei unterzubringen. Und zwar nicht durch Kompression, sondern durch "Beschreibung" der Information (weiss nicht, wie ich es besser ausdruecken soll. Vom Prinzip wohl aehnlich wie SVG). Folge mal den einzelnen Links, dann wird alles etwas klarer. Ich war am Anfang genauso verwirrt wie du.
Die Demo ".the .product" von ".farbrausch" ist ja schon legendär - ungefähr so bekannt, wie "2nd reality" von "Future Crew" seinerzeit 1993.
Der "Witz" bei dieser Demo ist, dass sämtliche Informationen dieser 15 Minuten langen Demo (für die Unwissenden: in diesem Fall kontinuierliche 3D-Animation, unterlegt mit Musik in CD-Qualität) mit hochspezialisierten Tools entweder vor Beginn der Demo erst ausgerechnet werden (wie beispielsweise die Texturen der 3D-Welten oder der Synthesizer für die Musik), oder mit ultraspezialisierten Tools bis auf das letzte Bit Redundanz zusammengepackt wurden (wie beispielsweise die Musik, welche im Prinzip nur als MIDI-Information gespeichert wurde, oder der Scrolltext am Demoende, bei dem man keinesfalls alle 8 Bit braucht).
Dass dadurch die ziemlich wahnsinnige Kompressionsrate von 1:300.000 herauskommt (die Enddaten also im Prinzip 300.000 Mal größer sind, als die nur 64 Kilobyte der ausführbaren Datei), ist für die Demo schlicht überwältigend. Für die Praxis aber leider irrelevant, denn es handelt sich hier strenggenommen nicht um ein Kompressionsverfahren, sondern um ein Generierungsverfahren.
- Sven Rautenberg
Hi Sven
Die Demo ".the .product" von ".farbrausch" ist ja schon legendär - ungefähr so bekannt, wie "2nd reality" von "Future Crew" seinerzeit 1993.
Oh, ich wusste nicht, dass diese Demos tatsaechlich so bekannt sind. Aber es kann ja nicht schaden, nochmal drauf aufmerksam zu machen ... ;-)
Für die Praxis aber leider irrelevant...
Das wuerde ich nicht unbedingt behaupten. Nehmen wir mal an, ich wuerde auf meiner Web Site Sounddateien und aehnliches zum Download anbieten. Dann wuerde sich das Vorausberechnen der Generierungsdaten mit Sicherheit lohnen, weil die Dateigroesse (z.B. fuer das Herunterladen)entsprechend schrumpft.
In einer der Borland Newsgroups, in denen ich zumeist aktiv bin, wird uebrigens gerade darueber diskutiert, ob man eventuell Kompressionsverfahren fuer Grafikdateien auf Basis der o.g. Methode entwickeln kann. Momentan scheiden sich noch die Geister, aber es gibt zumindest gewisse Ansaetze, die ggf. erfolgversprechend sein koennten. Die Idee, auf der die ".farbrausch" Demos basieren, ist zwar nicht neu, aber trotzdem faszinierend, wie ich finde.
Cheers
Uwe
Portland, OR
hi,
Für die Praxis aber leider irrelevant...
Das wuerde ich nicht unbedingt behaupten.
ich würde mich sven da aber auch anschliessen.
Nehmen wir mal an, ich wuerde auf meiner Web Site Sounddateien und aehnliches zum Download anbieten. Dann wuerde sich das Vorausberechnen der Generierungsdaten mit Sicherheit lohnen, weil die Dateigroesse (z.B. fuer das Herunterladen)entsprechend schrumpft.
du könntest ebenso wie die coder dieser demo bestimmte musik"stücke" _erzeugen_, in dem du ihre struktur beschreibst, und dann die eigentlichen musikdaten erzeugst.
das hat von der technik her ähnlichkeit mit z.b. dem MIDI format, in dem wird ja auch nur abgespeichert, welche note in der klangfarbe wechlen instrumentes wann und wie lange zu erklingen hat.
das ist aber noch ganz etwas anderes, also ein aktuelles musikstück auf diese weise zu speichern, wandle mal einen aktuellen chart-hit mit entsprechender software vom wave- ins midi-format um, das klingt eher grausam (OK, _chart_musik tut dies vorher vermutlich auch schon).
In einer der Borland Newsgroups, in denen ich zumeist aktiv bin, wird uebrigens gerade darueber diskutiert, ob man eventuell Kompressionsverfahren fuer Grafikdateien auf Basis der o.g. Methode entwickeln kann.
selbe argumentation wie oben:
diese "bilder" basieren hauptsächlich auf mathematischen algorithmen, die ihren aufbau beschreiben.
auf die gleiche weise deine urlaubsfotos zu komprimieren, kann deshalb nicht funktionieren, da du, deine freunde und der strand im hintergrund sich eben nicht so einfach als mathematische gleichungen beschreiben lassen.
gruss,
wahsaga
Gruess dich
auf die gleiche weise deine urlaubsfotos zu komprimieren, kann deshalb nicht funktionieren, da du, deine freunde und der strand im hintergrund sich eben nicht so einfach als mathematische gleichungen beschreiben lassen.
Einfach ist es sicherlich nicht, aber es gibt durchaus Ansaetze, wie man an dieses Problem rangehen kann (Stichwort "Descriptive Primitives").
Ciao
Uwe
Portland, OR