Abo
  1. Foren
  2. Kommentare
  3. Foto
  4. Alle Kommentare zum Artikel
  5. › Rückkehr der Paper Disk: 256 GByte auf A4…

Fake!

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. Fake!

    Autor: mathesechser 27.11.06 - 12:18

    Dass das ganze nicht gehen kann, muss jedem klar sein, der rechnen kann. Siehe http://arstechnica.com/news.ars/post/20061126-8288.html

  2. Re: Fake!

    Autor: gultimore 27.11.06 - 12:24

    sag doch nicht sowas.
    daß müßte ja bedeuten, ich kann in meinem jpg-bild keine 230gb daten speichern?

    mathesechser schrieb:
    -------------------------------------------------------
    > Dass das ganze nicht gehen kann, muss jedem klar
    > sein, der rechnen kann. Siehe arstechnica.com


  3. Re: Fake!

    Autor: JXR 27.11.06 - 12:26

    Ja. Das ist es sogar mir als Nicht-Informatiker, mit dem Grundwissen das man als Computerinteressierter so hat.

  4. Re: Fake!

    Autor: Hase 2.0 27.11.06 - 12:31

    gultimore schrieb:
    -------------------------------------------------------
    > sag doch nicht sowas.
    > daß müßte ja bedeuten, ich kann in meinem jpg-bild
    > keine 230gb daten speichern?

    Kannst Du schon. Wobei ich doch lieber ein TIF als Beispiel hernehmen wollte.

    Nur
    1) Wird Du es nicht auf einer A4 Seite unterbringen!
    2) Wirst Du es nicht so ausrucken können das Du es
    3) wieder so einscannen kannst dass Du Deine Daten zurückerhällst.

    Mit dicken fetten geometrischen Formen in einer überschaubaren Farbpalette könnte man sicher ein Paar MB in einem buchdicken Stapel unterbringen.

  5. Fehlerkorrektur

    Autor: @ 27.11.06 - 12:54

    für US Letter Format mal durchgerechnet:
    150dpi^2 * 8,5i * 11i = 2103750 bits bits

    dazu die Graustufeninformation:
    2103750 * 256 = 538560000 bits

    Annahme, dass die Farbauflösung 12 Bit beträgt:
    538560000 * (4096 / 256) = 8616960000 bits

    entspricht ca. 1 GByte

    Das wäre dann die Rohdatendichte ohne Fehlerkorrektur und mit vielleicht zu hoher dpi...

    mathesechser schrieb:
    -------------------------------------------------------
    > Dass das ganze nicht gehen kann, muss jedem klar
    > sein, der rechnen kann. Siehe arstechnica.com


  6. und das bekommst du mit einem scanner

    Autor: Ihr Name 2.0 27.11.06 - 12:57

    wieder so gut eingescannt dass du die enthaltenen daten wieder korrekt wiederherstellen kannst?

  7. Re: Fake!

    Autor: h.ludens 27.11.06 - 13:02

    mal davon abgesehen, daß ein standard-scan einer Din-A4-seite im Bitmap-format nicht umsonst um einiges über der auf dieser seite errechnetem wert liegt...was wohl daran liegt, daß er die farbinformation vergessen hat, in betracht zu ziehen...lass mich eine gegenrechnung aufstellen :
    also - nehmen wir seine 134 millionen pixel pro seite und geben wir jedem pixel eine farbinformation von 3 byte (rgb ohne alpha), dann können wir pro seite bei pixelgenauem scannen so etwa 383 MegaByte codieren (naja...rein theoretisch, zugegeben). aber - dabei ist der bildinhalt ja völlig außer betracht gelassen worden!
    gibt man jeweils vier benachbarten pixeln die gleiche farbe und wertet die 15 möglichen muster aus, die sich ergeben, wenn man nicht alle pixel druckt, ergeben sich schon knappe 1450 MegaByte.
    nimmt man 16er-würfel, ist man bei theoretischen anderthalb terabyte, wenn ich mich nicht verrechnet habe.
    das läßt natürlich jede fehlerkontrolle und wohl nötige quantisierungen völlig außer acht, sollte aber eine vorstellung geben, was theoretisch möglich wäre. naturlich ist das nicht im sinne der industrie und wohl auch auf consumer-geräten reine utopie...aber ich finde die idee trotzdem interessant. mfg h.ludens

  8. existierende Verfahren

    Autor: @ 27.11.06 - 13:03

    Vergleiche doch einfach mal mit existierenden Verfahren:
    https://forum.golem.de/read.php?14618,793081,793081#msg-793081

    4096 Farben sollten mindestens drin sein.

    Ihr Name 2.0 schrieb:
    -------------------------------------------------------
    > wieder so gut eingescannt dass du die enthaltenen
    > daten wieder korrekt wiederherstellen kannst?


  9. Re: Fake!

    Autor: X-stian X-mas 27.11.06 - 13:09

    h.ludens schrieb:
    -------------------------------------------------------

    > gibt man jeweils vier benachbarten pixeln die
    > gleiche farbe und wertet die 15 möglichen muster
    > aus, die sich ergeben, wenn man nicht alle pixel
    > druckt, ergeben sich schon knappe 1450 MegaByte.

    Das darfst du jetzt gerne noch einmal erklären, so dass ich es verstehe.

    X-stian

  10. Re: Fake!

    Autor: Dennis Boller 27.11.06 - 13:13

    Sehe ich das jetzt richtig: Die Methode erlaubt es 230GB daten in A4-Größe zu speichern? Warum das Bild ausdrücken. Selbst als Bitmap auf dem Rechner abgelegt ware es doch kleiner als man es mit ZIP schaffen würde, oder?

  11. Re: Fake!

    Autor: h.ludens 27.11.06 - 13:19

    stell dir einfach vier gleichfarbige pixel nebeneinander vor, dann kannst du das so aussehen lassen :
    .--- oder -.-- oder --.-- oder ---. oder ..-- oder -..- usw...mit zwei binären variablen (pixel ist gedruckt, pixel ist nicht gedruckt) lassen sich eben 15 kombinationen codieren. ok ?



  12. Re: Fake!

    Autor: h.ludens 27.11.06 - 13:25

    oder vielleicht ist es in würfel-form verständiger :
    . .
    . . entspricht binär 1111 oder der dezimalen 15

    . .
    . entspricht binär 1101 oder der dezimalen 13 usw....

    hilft das ? wenn ja, stell dir einfach vor, daß du mit würfeln aus je 16 pixeln dann nicht 15 werte, sondern über 65000 codieren kannst ((2^16)-1). das ist natürlich reine theorie, aber wer weiß schon, was die zukunft bringt :) mfg : h.ludens


  13. Re: Fake!

    Autor: X-stian X-mas 27.11.06 - 13:25

    h.ludens schrieb:
    -------------------------------------------------------
    > stell dir einfach vier gleichfarbige pixel
    > nebeneinander vor, dann kannst du das so aussehen
    > lassen :
    > .--- oder -.-- oder --.-- oder ---. oder ..-- oder
    > -..- usw...mit zwei binären variablen (pixel ist
    > gedruckt, pixel ist nicht gedruckt) lassen sich
    > eben 15 kombinationen codieren. ok ?

    Schon klar. Aber diese 4 Pixel mit RGB-Farbraum haben schon deutlich mehr Speicher (12 Byte) als deine 16(!) Möglichkeiten (4 bit). Und in den 12 byte sind die 4bit schon mit drin. D.h deine Muster sind eine Untermenge aller Farbvarianten der 4 Pixel. Oder habe ich da jetzt was übersehen?

    X-stian

  14. Re: Fake!

    Autor: huahuahua 27.11.06 - 13:28

    h.ludens schrieb:
    -------------------------------------------------------
    > mal davon abgesehen, daß ein standard-scan einer
    > Din-A4-seite im Bitmap-format nicht umsonst um
    > einiges über der auf dieser seite errechnetem wert
    > liegt...was wohl daran liegt, daß er die
    > farbinformation vergessen hat, in betracht zu
    > ziehen...lass mich eine gegenrechnung aufstellen
    > :
    > also - nehmen wir seine 134 millionen pixel pro
    > seite und geben wir jedem pixel eine
    > farbinformation von 3 byte (rgb ohne alpha), dann
    > können wir pro seite bei pixelgenauem scannen so
    > etwa 383 MegaByte codieren (naja...rein
    > theoretisch, zugegeben). aber - dabei ist der
    > bildinhalt ja völlig außer betracht gelassen
    > worden!
    > gibt man jeweils vier benachbarten pixeln die
    > gleiche farbe und wertet die 15 möglichen muster
    > aus, die sich ergeben, wenn man nicht alle pixel
    > druckt, ergeben sich schon knappe 1450 MegaByte.
    > nimmt man 16er-würfel, ist man bei theoretischen
    > anderthalb terabyte, wenn ich mich nicht
    > verrechnet habe.
    > das läßt natürlich jede fehlerkontrolle und wohl
    > nötige quantisierungen völlig außer acht, sollte
    > aber eine vorstellung geben, was theoretisch
    > möglich wäre. naturlich ist das nicht im sinne der
    > industrie und wohl auch auf consumer-geräten reine
    > utopie...aber ich finde die idee trotzdem
    > interessant. mfg h.ludens
    >
    >


    Danke, wollte eben selbst noch eine Rechnung aufstellen, die diese Möglichkeiten unterstreicht, doch Dein Beitrag erspart mir die Rechnerei.
    Wer mal eine A4-Seite mit mehr als 1200 dpi gescannt hat (was mit einem normalen Scanner Ewigkeiten dauert!!!), der weiß auch, was für eine Datei ihn erwartet, wenn er in BMP speichert.
    JPG wäre Unsinn, da hier verlustbehaftet komprimiert wird.
    Die zu klärende Frage wird wohl die Drucker-Scanner Farbkompatibilität sein, an der sich die Hersteller ja eh schon die Zähne ausbeißen. Lässt man allerdings eine gewisse Tolleranz zu und verzichtet dafür auf etwas Speicherplatz, so sollten die 256 GB schon machbar sein. Bleibt die Frage des Mediums, da Papier und Druckerfarben einem schnell sichtbar werdenden Verfall unterliegen.
    (Wäre mal zu Prüfen, wieviel Kapazität bei Schwarz-Weiß übrigbliebe.)
    Auch Verunreinigungen und Knicke sind wohl Gift für das Verfahren.
    Hier bin ich auf Antworten gespannt.
    Schließlich tut es unter Umständen schon weh, wenn mal eben 256 GB wichtiger Daten der Kaffeetasse zum Opfer fallen...;))

  15. Re: Fake!

    Autor: wurstwie 27.11.06 - 13:28

    h.ludens schrieb:
    -------------------------------------------------------
    > stell dir einfach vier gleichfarbige pixel
    > nebeneinander vor, dann kannst du das so aussehen
    > lassen :
    > .--- oder -.-- oder --.-- oder ---. oder ..-- oder
    > -..- usw...mit zwei binären variablen (pixel ist
    > gedruckt, pixel ist nicht gedruckt) lassen sich
    > eben 15 kombinationen codieren. ok ?
    >
    >
    aber ist das nicht genau was biärcode macht? um bei deinem beispiel hier zu bleiben:

    1000 oder 0100 oder 0010 oder 0001 oder 1100 oder 0110 etc?

    weil dann brauche ich ein bit pro pixel, was bedeutet dass ich genausoviele bit wie bildpixel speichern kann. oder?

  16. Re: Fake!

    Autor: h.ludens 27.11.06 - 13:30

    du nimmst je vier pixel und gibst ihnen die gleiche farbe. dadurch reduziert sich die datenmenge von 380 MB auf so etwa 95 MB, ok ? da du aber mit den entstandenen vierergruppen je 16 zustände darstellen kannst, entstehen im endeffekt eben 95 * 16 MB


  17. Re: Fake!

    Autor: se_ultimativ 27.11.06 - 13:31

    Dennis Boller schrieb:
    -------------------------------------------------------
    > Sehe ich das jetzt richtig: Die Methode erlaubt es
    > 230GB daten in A4-Größe zu speichern? Warum das
    > Bild ausdrücken. Selbst als Bitmap auf dem Rechner
    > abgelegt ware es doch kleiner als man es mit ZIP
    > schaffen würde, oder?

    liest du auch manchmal die _wichtigen_ Informationen?
    hint: irgendwo in diesem thread findest du einen link.

  18. LOL, watt 'ne Argumentation

    Autor: Amüsierter Leser 27.11.06 - 13:31

    h.ludens schrieb:
    -------------------------------------------------------
    > also - nehmen wir seine 134 millionen pixel pro
    > seite und geben wir jedem pixel eine
    > farbinformation von 3 byte (rgb ohne alpha), dann
    > können wir pro seite bei pixelgenauem scannen so
    > etwa 383 MegaByte codieren
    > (naja...rein theoretisch, zugegeben).

    Sehr theoretisch.
    Ich bin ja nicht mehr auf dem Laufenden, was aktuelle
    Scanner angeht, aber Deine Theorie basiert erstmal
    darauf, dass das Blatt perfekt im Scanner liegt.
    Sonst vermischen sich nämlich die Pixel und es ent-
    steht ein neues Muster :-)

    Der Scanner darf kein Staubkorn auf der Scheibe haben
    und außerdem muss die farbliche Auflösung so perfekt ist,
    dass der Ausdruck auch auf 24Bit exakt wieder
    eingescannt werden kann.

    Sobald eine Farbe ein klein wenig anders ist,
    war's das dann auch schon wieder. Das heißt, kein
    Vergilben, kein Licht, kein Schmutz aus der Luft,
    Anfassen wäre tötlich für die Daten.
    Die 'Halbwertszeit' solcher Datenträger würde
    vermutlich in Sekunden gemessen.

    Sehr hübsch auch die Idee mit dem Alpha-Wert.
    <kopfschüttel>

    > aber - dabei ist der
    > bildinhalt ja völlig außer betracht gelassen
    > worden!

    Das stimmt. Bisher ging jeder von der optimalen
    Form aus, nämlich, dass jeder Bildpunkt unabhängig
    einen Wert speichern kann.

    > gibt man jeweils vier benachbarten pixeln die
    > gleiche farbe und wertet die 15 möglichen muster
    > aus, die sich ergeben, wenn man nicht alle pixel
    > druckt, ergeben sich schon knappe 1450 MegaByte.

    Wer Halbwissen quadriert, weiß häufig nicht, dass
    es grade deswegen nicht größer wird...


    Also... Ich nehme 4 Bit, also nur noch 1/4 der
    Auflösung, damit kann ich 15 verschiedene Werte
    darstellen... (es sind übrigens 16...)

    Deiner Rechnung zu Folge ergibt das 15/4 der
    Speicherkapazität. Wobei Du vermutlich 16/4
    meintest...

    In Wirklichkeit ist verbraucht einer der 16
    möglichen Werte aber 4 mal soviel Information,
    um den einen zu speichernden Wert darzustellen.
    Dafür kann man auch nur 1/4 der Werte speichern.

    Also kommt unterm Strich raus: Nix.

    > nimmt man 16er-würfel, ist man bei theoretischen
    > anderthalb terabyte, wenn ich mich nicht
    > verrechnet habe.

    Und wie Du Dich hier verrechnest...

    > das läßt natürlich jede fehlerkontrolle und wohl
    > nötige quantisierungen völlig außer acht, sollte
    > aber eine vorstellung geben, was theoretisch
    > möglich wäre.

    Gut, dass uns das mal einer gesagt hat.
    Und gut dass da keiner drauf gehört hat, da wären wieder
    Forschungsgelder verschwendet worden ;-)

    > naturlich ist das nicht im sinne der
    > industrie und wohl auch auf consumer-geräten reine
    > utopie...aber ich finde die idee trotzdem
    > interessant. mfg h.ludens

    Ich auch... ich hätte nur meinen Namen nicht drunter
    geschrieben...

    Hätte ich ein Blöd...ähh Blog... dann wärst Du jetzt auf der
    ersten Seite.
    Meinen Glückwunsch :-)


    @Golem: Was ist das für eine absolut BLÖDSINNIGE MELDUNG!?

  19. LOL, watt 'ne Argumentation

    Autor: Amüsierter Leser 27.11.06 - 13:31

    h.ludens schrieb:
    -------------------------------------------------------
    > also - nehmen wir seine 134 millionen pixel pro
    > seite und geben wir jedem pixel eine
    > farbinformation von 3 byte (rgb ohne alpha), dann
    > können wir pro seite bei pixelgenauem scannen so
    > etwa 383 MegaByte codieren
    > (naja...rein theoretisch, zugegeben).

    Sehr theoretisch.
    Ich bin ja nicht mehr auf dem Laufenden, was aktuelle
    Scanner angeht, aber Deine Theorie basiert erstmal
    darauf, dass das Blatt perfekt im Scanner liegt.
    Sonst vermischen sich nämlich die Pixel und es ent-
    steht ein neues Muster :-)

    Der Scanner darf kein Staubkorn auf der Scheibe haben
    und außerdem muss die farbliche Auflösung so perfekt ist,
    dass der Ausdruck auch auf 24Bit exakt wieder
    eingescannt werden kann.

    Sobald eine Farbe ein klein wenig anders ist,
    war's das dann auch schon wieder. Das heißt, kein
    Vergilben, kein Licht, kein Schmutz aus der Luft,
    Anfassen wäre tötlich für die Daten.
    Die 'Halbwertszeit' solcher Datenträger würde
    vermutlich in Sekunden gemessen.

    Sehr hübsch auch die Idee mit dem Alpha-Wert.
    <kopfschüttel>

    > aber - dabei ist der
    > bildinhalt ja völlig außer betracht gelassen
    > worden!

    Das stimmt. Bisher ging jeder von der optimalen
    Form aus, nämlich, dass jeder Bildpunkt unabhängig
    einen Wert speichern kann.

    > gibt man jeweils vier benachbarten pixeln die
    > gleiche farbe und wertet die 15 möglichen muster
    > aus, die sich ergeben, wenn man nicht alle pixel
    > druckt, ergeben sich schon knappe 1450 MegaByte.

    Wer Halbwissen quadriert, weiß häufig nicht, dass
    es grade deswegen nicht größer wird...


    Also... Ich nehme 4 Bit, also nur noch 1/4 der
    Auflösung, damit kann ich 15 verschiedene Werte
    darstellen... (es sind übrigens 16...)

    Deiner Rechnung zu Folge ergibt das 15/4 der
    Speicherkapazität. Wobei Du vermutlich 16/4
    meintest...

    In Wirklichkeit ist verbraucht einer der 16
    möglichen Werte aber 4 mal soviel Information,
    um den einen zu speichernden Wert darzustellen.
    Dafür kann man auch nur 1/4 der Werte speichern.

    Also kommt unterm Strich raus: Nix.

    > nimmt man 16er-würfel, ist man bei theoretischen
    > anderthalb terabyte, wenn ich mich nicht
    > verrechnet habe.

    Und wie Du Dich hier verrechnest...

    > das läßt natürlich jede fehlerkontrolle und wohl
    > nötige quantisierungen völlig außer acht, sollte
    > aber eine vorstellung geben, was theoretisch
    > möglich wäre.

    Gut, dass uns das mal einer gesagt hat.
    Und gut dass da keiner drauf gehört hat, da wären wieder
    Forschungsgelder verschwendet worden ;-)

    > naturlich ist das nicht im sinne der
    > industrie und wohl auch auf consumer-geräten reine
    > utopie...aber ich finde die idee trotzdem
    > interessant. mfg h.ludens

    Ich auch... ich hätte nur meinen Namen nicht drunter
    geschrieben...

    Hätte ich ein Blöd...ähh Blog... dann wärst Du jetzt auf der
    ersten Seite.
    Meinen Glückwunsch :-)


    @Golem: Was ist das für eine absolut BLÖDSINNIGE MELDUNG!?

  20. Re: Fake!

    Autor: X-stian X-mas 27.11.06 - 13:39

    h.ludens schrieb:
    -------------------------------------------------------
    > du nimmst je vier pixel und gibst ihnen die
    > gleiche farbe. dadurch reduziert sich die
    > datenmenge von 380 MB auf so etwa 95 MB, ok ? da
    > du aber mit den entstandenen vierergruppen je 16
    > zustände darstellen kannst, entstehen im endeffekt
    > eben 95 * 16 MB

    Du nimmst 4 Pixel, die je 256 Farben darstellen können (4294967296 Möglichkeiten), und ersetzt alle durch die gleiche Farbe. Jetzt kannst du 16 Zustände darstellen. Es wird nur weniger. Ich sehe nicht, wie es mehr werden sollte. Die 16 Zustände sind in den 4294967296 Möglichkeiten schon berücksichtigt.

    Man kann nur entweder 4294967296 Möglichkeiten nutzen ODER 16 Zustände haben. Es gibt kein 4294967296 * 16.

    X-stian

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Sparkassenverband Bayern, Bayern
  2. WBS GRUPPE, Berlin
  3. kd-holding gmbh, Ehrenkirchen, Kirchhofen
  4. DPD Deutschland GmbH, Großostheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-55%) 6,75€
  2. 4,99€
  3. 4,99€
  4. 4,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Technologie: Warum Roboter in Japan so beliebt sind
Technologie
Warum Roboter in Japan so beliebt sind

Japaner produzieren nicht nur mehr Roboter als jede andere Nation, sie gehen auch selbstverständlicher mit ihnen um. Das liegt an der besonderen Geschichte und Religion des Inselstaats - und an Astro Boy.
Von Miroslav Stimac

  1. Kreativität Roboterdame Ai-Da soll zeichnen und malen
  2. Automatisierung Roboterhotel entlässt Roboter
  3. Cimon Die ISS bekommt einen sensiblen Kommunikationsroboter

Anno 1800 im Test: Super aufgebaut
Anno 1800 im Test
Super aufgebaut

Ach, ist das schön: In Anno 1800 sind wir endlich wieder in einer heimelig-historischen Welt unterwegs - zumindest anfangs. Das neue Werk von Blue Byte fesselt dank des toll umgesetzten und unverwüstlichen Spielprinzips. Auch neue Elemente wie die Klassengesellschaft funktionieren.
Von Peter Steinlechner

  1. Ubisoft Blue Byte Anno 1800 erhält Koop-Modus und mehr Statistiken
  2. Ubisoft Blue Byte Preload der offenen Beta von Anno 1800 eröffnet
  3. Systemanforderungen Anno 1800 braucht schnelle CPU

Swobbee: Der Wechselakku kommt wieder
Swobbee
Der Wechselakku kommt wieder

Mieten statt kaufen, wechseln statt laden: Das Berliner Startup Swobbee baut eine Infrastruktur mit Lade- und Tauschstationen für Akkus auf. Ein ähnliches Geschäftsmodell ist schon einmal gescheitert. Dieses kann jedoch aufgehen.
Eine Analyse von Werner Pluta

  1. Elektromobilität Seoul will Zweirad-Kraftfahrzeuge und Minibusse austauschen
  2. Rechtsanspruch auf Wallboxen Wohnungswirtschaft warnt vor "Schnellschuss" bei WEG-Reform
  3. Innolith Energy Battery Schweizer Unternehmen entwickelt sehr leistungsfähigen Akku

  1. Laminas: Linux Foundation führt Zend Framework weiter
    Laminas
    Linux Foundation führt Zend Framework weiter

    Das Zend Framework, eine Sammlung professioneller PHP-Pakete zur Entwicklung von Web-Anwendungen, geht in die Obhut der Linux Foundation über. Das Konsortium will das Zend Framework dann als Open-Source-Projekt Laminas weiterführen, noch fehlen aber zahlungswillige Unterstützer.

  2. Deutsche Telekom: Letzte gelbe Telefonzelle Deutschlands ist abgebaut
    Deutsche Telekom
    Letzte gelbe Telefonzelle Deutschlands ist abgebaut

    Eine Zeit, die viele junge Menschen nicht mehr kennen, endet: In Südbayern ist die letzte gelbe Telefonzelle Deutschlands abgebaut worden - zu wenig Umsatz bei zu hohen Kosten.

  3. Fortnite: Bislang knapp 1.200 Sperren im Millionenturnier
    Fortnite
    Bislang knapp 1.200 Sperren im Millionenturnier

    Antreten in mehreren Regionen und Accountsharing: Epic Games hat nach der ersten Runde im Fortnite World Cup 2019 knapp 1.163 Nutzerkonten gesperrt. Nur ein Mal ist den Veranstaltern der Einsatz von Cheatsoftware aufgefallen.


  1. 13:32

  2. 12:55

  3. 12:37

  4. 12:25

  5. 12:10

  6. 11:57

  7. 11:51

  8. 11:50