PureBoard

Hi

Ich schreib mir grade was, daß mir Bereiche mit z.B 3000Bytes von großen Medien Dateien vergleichen soll (MD5 & CRC sind mir viel zu lahm, und so genau brauch ich es auch nicht, selbst
wenn mann die selbe Medien Datei 2 mal mit den selben Settings konvertiert ist sogar schon die Dateigröße anders, habs zig mal ausprobiert, mit xvid,x264,wmv usw usw)
und eine Prüfsumme erstellt.

Da war doch irgendwas das im grunde für'n Computer nur alles einsen und nullen sind. (wer lachen will, hat jetzt Gelegenheit dazu )



Sprich dann müsste ich doch mit

ReadData(#FileA,*Buffer1,3000) 3000 einsen und nullen einlesen, aber wie kriege ich die auch angezeigt ?

PeekS zeigt natürlich nur Müll bei Binärdaten an, und alle anderen Peek Befehle ergeben für mich auch kein Sinn.

Denn selbst wenn ich nur 1 Byte auslese, und z.B PeekL benutze, ist der Rückgabewert ne 10 stellige Zahl. Wie kann das denn sein ? bei PeekB sind es immer noch 3 Stellen.

Kann mich Bitte jemand aufklären ? Ich brauch den Binärwert, nur 0 und 1 als Ausgabe und das mit einer Länge die mann selbst bestimmt.

Denn natürlich bringt es mir nichts, wenn es heist

"Liest einen X-Wert (Y Bytes) von der angegebenen Speicheradresse."

">einen<" ja toll und von welcher Position b.z.w welchen ? ist das zufallsbedingt ? sprich einmal von da und ein anderes mal von wo völlig anders ?

Was genau hast du vor?

N00B hat geschrieben:Binär Daten vergleichen?

Dafür gibt es CompareMemory()

N00B hat geschrieben:ReadData(#FileA,*Buffer1,3000) 3000 einsen und nullen einlesen, aber wie kriege ich die auch angezeigt ?

Nein, ein Byte hat 8 Bits (Einsen und Nullen) du hast also 24000 Einsen und Nullen.
Damit können die Dezimalzahlen 0 bis 255 dargestellt werden.

N00B hat geschrieben:]Kann mich Bitte jemand aufklären ? Ich brauch den Binärwert, nur 0 und 1 als Ausgabe und das mit einer Länge die mann selbst bestimmt.

Das wäre aber keineswegs schnell. Und ich bezweifel, dass du Binärdaten mit den bloßen Auge vergleichen kannst.

N00B hat geschrieben:">einen<" ja toll und von welcher Position b.z.w welchen ? ist das zufallsbedingt ? sprich einmal von da und ein anderes mal von wo völlig anders ?

Ja einen, nämlich der, der an der Position steht, du DU angibst.

Danilo hat geschrieben:

N00B hat geschrieben:

"Liest einen X-Wert (Y Bytes) von der angegebenen Speicheradresse."

">einen<" ja toll und von welcher Position b.z.w welchen ? ist das zufallsbedingt ? sprich einmal von da und ein anderes mal von wo völlig anders ?

Ja, das ist reiner Zufall. Einmal von da und ein anderes mal von wo völlig anders. So ist eben Zufall,
das kann man nicht beeinflussen.

PS: Im "Absolute Anfänger" Forum wäre das besser aufgehoben, aber selbst absolute Anfänger denken selbst, bevor sie ihre Fragen formulieren.

"ReadData(#FileA,*Buffer1,3000)" liest 3000 Bytes, also 24.000 Nullen und Einsen. Ein Byte besteht aus 8 Nullen und Einsen.
Wenn Du die Daten binär anzeigen möchtest, solltest Du die Byte-Weise durch gehen und mit Bin() anzeigen.
Bin() wandelt Binärdaten (Nullen und Einsen) in menschlich lesbare Strings um. Das solltest auch Du lesen können.

Lachen darf mann, aber beleidigen lassen muss ich mich nicht

Das was du Genie mir vollidioten der zu dumm zum denken und lesen ist da beschreibst hab ich schon längst in meinem Code drin, nur das ein Byte 8 stellig ist wusste ich nicht, musste mich nie mit beschäftigen, dachte es währe nur einstellig.

Mal abgesehen davon, daß ich diese Kleinigkeit nicht wusste, hab ich sehr wohl auch schon die Möglichkeit in Betracht gezogen gehabt, aber wieder verworfen, denn was ich als
Rückgabe von z.B PeekB kriege, sind Zahlen pro Stelle zwischen 0 und 9, da ich dachte das ein Byte Wert mir 0 & 1 ausgeben sollte.

War einfach nur falsch gedacht, ein Denkfehler.

Und das kriege ich über Bin raus bei PeekB

Filesize=171787820
ROUND=0
Byte=112
Bin=1110000
Active File Pos=31233948

ROUND=1
Byte=54
Bin=110110
Active File Pos=46850922

ROUND=2
Byte=-103
Bin=1111111111111111111111111111111111111111111111111111111110011001
Active File Pos=62467896

Und da soll ich keinen Denkfehler kriegen ?

Schliesslich krieg ich erst was 8 stelliges raus, und später was mit 64 Stellen, obwohl ich PeekB benutzt habe, und Bin auf dem Rückgabewert von PeekB.

Und auf dein neuen Post gehe ich gar nicht mehr ein, für mich hat sich das Gespräch mit dir erledigt in dem Moment als mich beleidigt hast.

Und es ist millionenfach schneller (und trotzdem sehr zuverlässig um auf Duppe Files bei Mediendateien zu testen) Binärdaten an 10 Stellen in 2 Mediendateien von selber Dateigröße von z.B 2GB Datei zu vergleichen, als mit dem MD5Filefingerprint Müll.

EDIT: Ah das Genie hat sich falsch korrigiert, von ein Byte hat 8 Stellen auf 16.

Erste Aussage

liest 3000 Bytes, also 24.000 Nullen und Einsen. Ein Byte besteht aus 8 Nullen und Einsen.

Zweite Aussage

liest 3000 Bytes, also 48.000 Nullen und Einsen. Ein Byte besteht aus 16 Nullen und Einsen.

Bevor mann seine Antwort formuliert sollte mann denken !

EDIT2: Ah das Genie hat seinen Post nochmals korrigiert, wieder zurück von ein Byte hat 16 Stellen und 48.000 Nullen & Einsen auf 8 Stellen und 24.000 Nullen & Einsen.

http://www.elektronik-kompendium.de/sit ... 702271.htm

Seit wann hat ein Byte 16 Bit (16 Stellen)? Meines erachtens hat ein Byte 8 Bit mit jeweils 2 Zuständen, woduch ein Byte bis zu 256 Zustände annehmen kann. Oder lügt uns jetzt die etablierte Informatik-Literatur an?

Jungs ihr macht euch gerade irgendwie selber fertig, oder?

TroaX hat geschrieben:http://www.elektronik-kompendium.de/sit ... 702271.htm

Seit wann hat ein Byte 16 Bit (16 Stellen)? Meines erachtens hat ein Byte 8 Bit mit jeweils 2 Zuständen, woduch ein Byte bis zu 256 Zustände annehmen kann. Oder lügt uns jetzt die etablierte Informatik-Literatur an?

Jungs ihr macht euch gerade irgendwie selber fertig, oder?

Endlich mal einer der es mir so erklärt das ich es auch raffe (jetzt ergibt das mit 3 Stellen bei PeekB auch Sinn für mich) und es mit Humor nimmt statt mich zu beleidigen.

Ich weiß jetzt nicht, woher du Danilos Zitat her hast, aber zu der Ausgabe des Debuggers fehlt der Code den du dafür benutzt hast.

Bin() hat einen 2. Parameter, wo du kanngeben kannst, welcher Typ von Binärdaten übergeben wurde.
In deiem Fall #PB_Byte

Und es ist millionenfach schneller (und trotzdem sehr zuverlässig um auf Duppe Files bei Mediendateien zu testen) Binärdaten an 10 Stellen in 2 Mediendateien von selber Dateigröße von z.B 2GB Datei zu vergleichen, als mit dem MD5Filefingerprint Müll.

Wenn du prüfen willst, ob zwei Dateien möglicherweise ungleich sind ja. Es ist allerdings nicht sichergestellt, das bei 10 gleichheiten auch die ganze Datei gleich ist.

Eigentlich gehört das in den Mathematik-Unterricht der Grundschule, aber das wird heutzutage wohl
vernachlässigt.

Wichtigste Zahlen-Systeme für die Programmierung:
Das Dualsystem (auch Binärsystem): http://de.wikipedia.org/wiki/Dualsystem
Das Hexadezimalsystem: http://de.wikipedia.org/wiki/Hexadezimalsystem

STARGÅTE hat geschrieben:Ich weiß jetzt nicht, woher du Danilos Zitat her hast, aber zu der Ausgabe des Debuggers fehlt der Code den du dafür benutzt hast.

Bin() hat einen 2. Parameter, wo du kanngeben kannst, welcher Typ von Binärdaten übergeben wurde.
In deiem Fall #PB_Byte

Und es ist millionenfach schneller (und trotzdem sehr zuverlässig um auf Duppe Files bei Mediendateien zu testen) Binärdaten an 10 Stellen in 2 Mediendateien von selber Dateigröße von z.B 2GB Datei zu vergleichen, als mit dem MD5Filefingerprint Müll.

Wenn du prüfen willst, ob zwei Dateien möglicherweise ungleich sind ja. Es ist allerdings nicht sichergestellt, das bei 10 gleichheiten auch die ganze Datei gleich ist.

Voll das Kino hier

Ok jetzt sehe ich es auch, der andere (der sein Post gelöscht hat, während ich meinen verfasst habe, bin dann auf Preview dann hies es der Post existiert nicht, bin dann auf zurück und direkt auf Quote ohne zu schauen wenn ich da zittiere) hat mich beleidigt. Sorry das ich auf dich los bin.

Ah das mit dem 2. Parameter bei Bin hab ich nicht bedacht. Danke für die Info

Die Methode die ich anwenden will, reicht völlig aus für .avi, .wmv usw Dateien

Probier es selbst aus, nimm eine Datei, Codier sie einmal, und danach gleich nochmal mit identischen Settings, nicht nur die Dateigröße ändert sich, auch der Inhalt, die Codecs erzeugen selbst mit gleichen Settings bei der selben Datei nie den selben Binärwert an 10 Positionen, meist ist schon die erste Position total anders

Ich prüfe ja nicht, ob ein Bit oder Byte von der vermeintlich selben Medien Datei anders ist (glaub MD5Filefingerprint und CRC32 machen das, und sind desshalb so unglaublich langsam)
um zu prüfen ob die Datei verändert wurde, und zu 1000000000000000% gleich ist, sondern nur
ob es sehr warschenlich die selbe Datei ist. Da ich extrem viel Medien Files auf meinen 5 externen HD's habe, und gewiss auch vieles doppelt, brauch ich nenn sehr schnellen Code, und bisher hat Code immer die Dupes zuverlässig aufgespürt

ts-soft hat geschrieben:Eigentlich gehört das in den Mathematik-Unterricht der Grundschule, aber das wird heutzutage wohl
vernachlässigt.

Wichtigste Zahlen-Systeme für die Programmierung:
Das Dualsystem (auch Binärsystem): http://de.wikipedia.org/wiki/Dualsystem
Das Hexadezimalsystem: http://de.wikipedia.org/wiki/Hexadezimalsystem

Hab ich schon angeschaut (jedenfalls die Erklärung zum Binär Zahlensystem im Online PB Handbuch) und ich raffe es bis heute nicht

Als Linkshänder benutze ich mehr die rechte Gehirnhälfte, hab es nicht so mit Hex & Binär Zahlensystem.

Probier es selbst aus, nimm eine Datei, Codier sie einmal, und danach gleich nochmal mit identischen Settings, nicht nur die Dateigröße ändert sich, auch der Inhalt, die Codecs erzeugen selbst mit gleichen Settings bei der selben Datei nie den selben Binärwert an 10 Positionen, meist ist schon die erste Position total anders

Das liegt daran, das du eine kodierte Datei erneut kodierst, wodurch die Datenbasis beim 2. kodieren eine andere ist als beim ersten kodieren.

Wenn du also einen Codec über ein Video jagst, wird die Datei komprimiert und dabei kodiert. Das geschieht allerdings nur mit Datenverlust, wodurch meist die Qualität der Daten leiden wird. Der Qualitätsverlust ist bei dem einen Codecs stärker offentsichtlich wie bei einem anderen. Beim dekodieren (abspielen oder erneutes kodieren) sind somit die Daten komplett anders als das ursprüngliche Ausgangsvideo. Wenn du also den dekodierten Stream (der ja schon anders ist als das Ursprungsvideo) erneut kodierst, ändert sich natürlich durch die abweichende Datenbasis das Endergebnis nach der 2. kodierung erneut. Weswegen logischerweise alle kodiersteps unterschiedliche Files produzieren, auch wenn die Settings identisch sind

*EDIT* Kann auch sein das ich das jetzt falsch verstanden habe. Wenn du meinst, ein und die selbe Datei 2 mal zu kodieren, um das Ergebnis zu vergleichen, dann kann es unter Umständen dann an variablen werten liegen. Zum Beispiel VBR beim Audiostream oder vllt. sogar VBR beim Framestream. In beiden fällen bekommt man selten ein und das selbe Ergebnis raus, da das errechnen der Bitraten, die für die einzelnen Passagen notwendig sind immer wieder neu angesetzt werden müssen und dabei durch äußere Einflüsse wie unterschiedliche Auslastungen und unterschiedlich groß eingelesene Datenfragmente variieren kann. Das habe ich schon in der Audio-Komprimierung mit MP3 festgestellt. Das ist nichts neues.

TroaX hat geschrieben:

Probier es selbst aus, nimm eine Datei, Codier sie einmal, und danach gleich nochmal mit identischen Settings, nicht nur die Dateigröße ändert sich, auch der Inhalt, die Codecs erzeugen selbst mit gleichen Settings bei der selben Datei nie den selben Binärwert an 10 Positionen, meist ist schon die erste Position total anders

Das liegt daran, das du eine kodierte Datei erneut kodierst, wodurch die Datenbasis beim 2. kodieren eine andere ist als beim ersten kodieren.

Wenn du also einen Codec über ein Video jagst, wird die Datei komprimiert und dabei kodiert. Das geschieht allerdings nur mit Datenverlust, wodurch meist die Qualität der Daten leiden wird. Der Qualitätsverlust ist bei dem einen Codecs stärker offentsichtlich wie bei einem anderen. Beim dekodieren (abspielen oder erneutes kodieren) sind somit die Daten komplett anders als das ursprüngliche Ausgangsvideo. Wenn du also den dekodierten Stream (der ja schon anders ist als das Ursprungsvideo) erneut kodierst, ändert sich natürlich durch die abweichende Datenbasis das Endergebnis nach der 2. kodierung erneut. Weswegen logischerweise alle kodiersteps unterschiedliche Files produzieren, auch wenn die Settings identisch sind

Ne Troax ich glaub du hast mich falsch verstanden, ich kodiere die selbe Datei, 2 mal mit den selben Settings (ich nehme also nicht die Ausgabedatei und Codiere die noch mal, und guck dann ob Dupe, ist ja klar das die dann unterschiedlich sind, ich mag bei Zahlen und im Coden ne Niete sein, aber mit Codecs kenn ich mich nach 10 Jahren Praxis sehr gut aus ) nur der Ausgabedateiname ändert sich, trotzdem ist die Dateigröße anders, und der Binär Inhalt auch

Beim 2Pass Verfahren wird ja die FirstPass Info Datei (nennen wir sie mal FirstPass.cfg) die im ersten Durchgang erstellt wurde, wieder benutzt. Ich hab x264 so eingestellt das es selbst im x ten Durchgang die FirstPass.cfg nie modifiziert wird, ausser die Settings ändern sich, und trotzdem ist die Dateigröße minimal anders und der Binär Inhalt deutlich

EDIT: Ja sehe grade du hast mich falsch verstanden gehabt, deine Erklärung warum das so ist, ist sehr interessant.