Dragon 32 Homecomputer Kassetten in ASCII umwandeln...

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ja, eigentlich gibt es schon diverse tools dafür, aber ich finde es sehr Interessant, das mal selber zu machen:

Kassetten bzw. Aufnahmen davon als WAV Dateien in Python umzuwandeln in ASCII (.BAS) oder (später) in BINÄR Dateien...

Die "0" und "1" in den WAV Daten sind, ist von den Grundlagen her in diesem Bild gut zu sehen:
http://en.wikipedia.org/wiki/File:Fsk.svg
Siehe: http://de.wikipedia.org/wiki/Frequenzumtastung

Den Aufbau des Audio-Signals Vom Dragon hier u.a. hier beschrieben:
http://www.onastick.clara.net/cosio.htm
http://www.cs.unc.edu/~yakowenk/coco/te ... ormat.html

Das Format vom Dragon ist wohl auch das gleiche wie von einigen "CoCo" Homecomputer Modellen... Was es nicht ist, ist das sog. Kansas City standard Format. Zu dem es hier ein netten Blog-Eintrag mit Python-Skript gibt: http://dabeaz.blogspot.de/2010/08/using ... sette.html

Mein erster Ansatz ist hier: https://github.com/jedie/python-code-sn ... ragon%2032
Dort liegen auch zwei WAV Dateien, zum testen.

Bisher werden allerdings nur der 0,1 Bitstrom angezeigt. Die Ausgabe sieht dann so aus:

Code: Alles auswählen

Read 'HelloWorld1 origin.wav'...
Numer of audio frames: 109923
Framerate: 44100
samplewidth: 2
channels: 1
struct_unpack_str: <h
00100000001010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010001111000000000011110000000001000
00001000000010000000100000001000000010000000100000001000000000000000000
00000000000000000000000000000000000000001111000010101010000000000000000
00000000010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010101010101010101010101010
10101010101010101010101010101010101010101010101010101010101010101010101
01010101010101010101010101010101010101010101010001111001000000001001100
01111000010010000000000001010000000000010000010010010010000001001101001
10000010010001100000001000011110000000100100011000000110000000000011110
00100101000000000000101000111000000000010010010010110111000100010000010
01010100010001100100011001011110010000001001110101011110010010010100011
00100010001010000100010001000000000001111000100011000000000001111000110
10000000001001001001000000000000000000000000011101010101010101010101000
2734 bits decoded.
Ob die Daten stimmen, weiß ich noch nicht. Aber zumindest sieht das vom Aussehen her schon recht gut aus.

Ein Problem ist der "Startpunkt", den ich unten mit "even_odd" festlege. Wenn der falsch gewählt ist, kommt nur Käse raus.
Eine Idee, was man machen könnte: Man probiert mit einen Wert und testet ob man den Header mit "010101..." Folge kommt. Wenn nicht, dann anderen Wert nehmen und von vorn Probieren...

Generell funktioniert das "erkennen" der Sinus-Kurve so, das ich einfach nachsehe ob eine Anzahl (MIN_TOGGLE_COUNT) an sample Werten alle positiv oder negativ ist...
Hatte auch überlegt nach Werten zu schauen die kontinuierlich größer oder kleiner werden. So würde man die Flanken der Sinuskurve finden. Hätte den Vorteil, das die Symmetrie beim Nulldurchgang egal ist...

Keine Ahnung wie ich nun weiter machen könnte...

Immer her mit Verbesserungsvorschläge, bitte!

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Zennoe
User
Beiträge: 16
Registriert: Montag 12. August 2013, 21:46

Ich habe zwar keine Ahnung von einem Dragon 32, weder noch von den Kasetten, die er benutzt. Was ich aber weiß ist, dass man .wav-Datei mit einem Media-Player abspielen soll. Wieso willst du sie also in ASCII umwandeln? :K

Code: Alles auswählen

print("Zennoe sprach!")
Ja, das hat er!
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Du kennst nicht "Kassetten" als Datenspeicher für Homecomputer? Vielleicht sagt dir "Datasette" vom C64 was? Siehe: http://de.wikipedia.org/wiki/Datassette

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
bfm
User
Beiträge: 88
Registriert: Donnerstag 14. März 2013, 09:42

@jens:
Du musst bedenken, es gibt hier auch noch jüngere Forumsmitglieder, die könnten vom Alter her unsere Kinder sein ;-)

Im Jahr 1986 hatten wir in der Schule das hier: http://www.classiccomputer.de/ams/cpc464main.jpg

lg
Benutzeravatar
kbr
User
Beiträge: 1504
Registriert: Mittwoch 15. Oktober 2008, 09:27

bfm hat geschrieben:Im Jahr 1986 hatten wir in der Schule das hier: http://www.classiccomputer.de/ams/cpc464main.jpg
Nicht übel! In der Schule hatten wir so was: http://sliderules.lovett.com/toprules/g ... 2491/2.jpg
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

:lol: :lol: :lol:


Bin ein wenig weiter:

HelloWorld1 origin.wav

Code: Alles auswählen

Numer of audio frames: 109923
read...
Framerate: 44100
samplewidth: 2
channels: 1
struct_unpack_str: <h
2735 bits decoded.
Start leader '01010101' found at position: 9
bits before header: 001000000
Block pos: 1016-192 len: 192bits rest: 1518bits
-------------------------------------------------------------------------------
  *** file info block data:
01010100 01111000 00000001 11100000 00001000 00001000 00001000 00001000
00001000 00001000 00001000 00001000 00000000 00000000 00000000 00000000
00000000 00000000 00000001 11100001 01010100 00000000 00000000 00000001
-------------------------------------------------------------------------------
  *** data block 1
  Block pos: 1024-440 len: 192bits rest: 54bits
01010100 01111001 00000000 10011000 11110000 10010000 00000000 10100000
00000010 00001001 00100100 00001001 10100110 00001001 00011000 00001000
01111000 00001001 00011000 00011000 00000000 11110001 00101000 00000000
01010001 11000000 00001001 00100101 10111000 10001000 00100101 01000100
01100100 01100101 11100100 00001001 11010101 11100100 10010100 01100100
01000101 00001000 10001000 00000000 11110001 00011000 00000000 11110001
10100000 00001001 00100100 00000000 00000000 00000001 11010101
-------------------------------------------------------------------------------
  *** data block 2
  Block pos: 8-0 len: 192bits rest: 0bits
01010100 01111001 11111110 00000001 11111111 010101
-------------------------------------------------------------------------------
HelloWorld1 xroar.wav

Code: Alles auswählen

Numer of audio frames: 75025
read...
Framerate: 22050
samplewidth: 1
channels: 1
struct_unpack_str: b
4760 bits decoded.
Start leader '01010101' found at position: 2
bits before header: 11
Block pos: 2048-160 len: 160bits rest: 2550bits
-------------------------------------------------------------------------------
  *** file info block data:
01010100 01111000 00000001 11100000 00001000 00001000 00001000 00001000
00001000 00001000 00001000 00001000 00000000 00000000 00000000 00000000
00000000 00000000 00000001 11100001
-------------------------------------------------------------------------------
  *** data block 1
  Block pos: 2056-440 len: 160bits rest: 54bits
01010100 01111001 00000000 10011000 11110000 10010000 00000000 10100000
00000010 00001001 00100100 00001001 10100110 00001001 00011000 00001000
01111010 00001001 00011000 00011000 00000000 11110001 00101000 00000000
01010001 11000010 00001001 00100101 10111000 10001000 00100101 01000100
01100100 01100101 11100100 00001001 11010101 11100100 10010100 01100100
01000101 00001000 10001000 00000000 11110001 00011000 00000000 11110001
10100010 00001001 00100100 00000000 00000000 00000001 11010101
-------------------------------------------------------------------------------
  *** data block 2
  Block pos: 8-0 len: 160bits rest: 0bits
01010100 01111001 11111110 00000001 11111111 010101
-------------------------------------------------------------------------------

Source: https://github.com/jedie/python-code-sn ... _decode.py


Nun frage ich mich, wie die einzelnen bits denn in byte gewandert werden können.


EDIT: Ich hab noch mal nachgesehen, in den beiden WAV file ist das selbe listing:

Code: Alles auswählen

10 FOR I = 1 TO 10
20 PRINT I;"HELLO WORLD!"
30 NEXT I
Von den bit wusel oben, kann man sehen, das anscheinen im "data block 1" das selbe ist. Ich glaube darin steck auch das eigentliche listing.
(Frage mich allerdings warum da einmal 192bits und einmal 160bits steht)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
darktrym
User
Beiträge: 785
Registriert: Freitag 24. April 2009, 09:26

Ein Glück, ich dachte schon ich wäre der einzige Freak der sich 2013 noch mit Kassettenformat und deren Archivierung bspw. in TZX beschäftigt.
„gcc finds bugs in Linux, NetBSD finds bugs in gcc.“[Michael Dexter, Systems 2008]
Bitbucket, Github
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@jens:
Weiss nicht, wie Du das mit dem Finden des Startpunktes gelöst hast (habs mir nicht angeschaut), als Idee - Du könntest den Bitstrom in ein ctypes.c_uint als Sentinel-Ringpuffer solange füttern, bis der richtige 32bit-Wert gefunden wurde.
Ungetestet:

Code: Alles auswählen

sentinel = c_uint()
i_bits = iter(bits)
for bit in i_bits:
    sentinel.value <<= 1
    sentinel.value |= bit
    if sentinel.value == <gesuchte erste 32bit des Headers>:
        break
# weiter mit i_bits
Der Iterator zeigt dann quasi auf Header-Start + 32, von da an kannst Du dann die Datenwörter erstellen. Sollten die ersten 32bit nicht ausreichen oder zuviel des Guten sein und schon variable Daten enthalten, kannst Du ja den Ringpuffer entsprechend vergrößern oder verkleinern.

Edit: c_uint verbessert -.-
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Interessante Idee, auch wenn ich nur einen kleinen Teil verstanden hab :oops:

Generell ist mein Wissen um bits und bytes begrenzt...

Das mit dem richtigen Startpunkt habe ich bisher nicht angegangen. Idee dazu hab ich allerdings, was man mit deinem verbinden kann:
Erstmal sollte ich schauen, ab wann überhaupt Daten kommen. Also i.d.R. hat man erstmal eine weile Stille bzw. mehr oder weniger lautes Rauschen.
Wenn ich die Stelle mit den Daten wirklich gefunden habe, könnte ich ein paar Sekunden vom WAV nehmen und einmal probieren ob ich "01010101" finden kann. Wenn nicht, dann den bool even_odd negieren und nochmal probieren...

Aber das kann man später versuchen.

z.Z. würde ich gern einfachmal die ersten Daten "sehen", doch bekommen nur Müll raus.
Zum Umwandeln von bits in bytes hab ich das gemacht:

Code: Alles auswählen

def bits2byte(bits):
    """
    >>> bits2byte([0,1,0,1,0,1,0,1])
    170

    >>> byte = bits2byte([1,0,1,0,1,0,1])
    >>> byte, hex(byte), bin(byte), chr(byte)
    (85, '0x55', '0b1010101', 'U')

    >>> ord("A")
    65
    >>> hex(65)
    '0x41'
    >>> bin(65)
    '0b1000001'
    >>> byte = bits2byte([1,0,0,0,0,0,1])
    >>> byte, hex(byte), bin(byte), chr(byte)
    (65, '0x41', '0b1000001', 'A')
    """
    byte = 0
    for no, bit in enumerate(bits):
        byte = byte | (bit << no)
    return byte
Das geht bestimmt auch einfacher...

Hab was interessantes bei http://www.coco3.com/community/2010/12/ ... cas-files/ gefunden.
Ein Python Skript bin2cas.py was folgendes können soll: converter binary files to .cas used on CoCo2 emulators like XRoar
Der Original Code: http://pastebin.com/GCw1NAeY
Diesen habe ich mal neu formatiert, sah ja schrecklich aus. Neue Version: http://pastebin.com/wMHqLN9N

Getestet habe ich es nicht. Aber das hilft mir die Information über das Datenformat von http://www.cs.unc.edu/~yakowenk/coco/te ... ormat.html besser zu verstehen.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Du solltest deine bits2byte-Funktion nicht mit symmetrischen Daten testen ;-) Wie bei dezimalzahlen auch, steht die Ziffer mit dem niedrigsten Wert überlichweise auf der rechten Seite und das mit dem höchstwertigen auf der linken. Bei dir ist das jedoch umgekehrt und damit sehr verwirrend. Hättest du dein ersten Test kurz in der Konsole überprüft, dann wäre dir das wohl auch aufgefallen ;-)

Code: Alles auswählen

>>> int("01010101", 2)
85
Für einen Datenstrom ist die jetzige Herangehensweise möglicherweise in Ordnung, dann solltest du die Namen allerdings entsprechend anpassen. Wie sieht es eigentlich mit der Endianness des Dragon aus?
Das Leben ist wie ein Tennisball.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ah, danke!

Das ist auf meine Lücken im Basis-Wissen zurück zu führen.

Dann ist die Reihenfolge entscheident? Und auch wo "füll"-Bits hinkommen?

EDIT: Lese gerade http://de.wikipedia.org/wiki/Byte-Reihenfolge

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Wie sähe denn dann eine byte2bit und bit2byte Funktion aus, die wahlweise in "Big Endian", "Little Endian" oder "Middle Endian" arbeitet?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Sirius3
User
Beiträge: 18253
Registriert: Sonntag 21. Oktober 2012, 17:20

läßt man von Deinen Daten die ersten 7 Bit weg, so kann ich immerhin den String "HELLO WORLD!" lesen. Der Rest scheinen binär kodierte BASIC-Befehle zu sein.

Code: Alles auswählen

>>> data="""0 01111001 00000000 10011000 11110000 10010000 00000000 10100000
... 00000010 00001001 00100100 00001001 10100110 00001001 00011000 00001000
... 01111010 00001001 00011000 00011000 00000000 11110001 00101000 00000000
... 01010001 11000010 00001001 00100101 10111000 10001000 00100101 01000100
... 01100100 01100101 11100100 00001001 11010101 11100100 10010100 01100100
... 01000101 00001000 10001000 00000000 11110001 00011000 00000000 11110001
... 10100010 00001001 00100100 00000000 00000000 00000001 11010101"""
>>> ''.join(map(lambda a:chr(int(a[::-1],2)),re.sub('([01]{8})',r'\1 ',re.sub('\s','',data)).split()))
'<\x012\x1e\x12\x00\n\x80 I \xcb 1 \xbc 10\x00\x1e)\x00\x14\x87 I;"HELLO WORLD!"\x00\x1e1\x00\x1e\x8b I\x00\x00\x00W\x01'
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Ok vllt sollte man die Spec vorher lesen :oops: - bei einem 8bit header würde für meinen Vorschlag ein ctypes.c_ubyte reichen.

Wie verrauscht/alt/kaputt sind denn die Kasetten? Das Format hat ja nicht gerade viele Checksums drin, was möglicherweise schon beim Finden des Headers zu Problemen führt.

Die Datenwörter scheinen 8bittig zu sein, daher sollte mit dem richtigen Startpunkt das einfach in Bytes zu überführen sein. Die Endiness musst Du halt entsprechend anpassen. Falls du nicht weisst ob big oder little - die Spec verzeichnet einen filename-Block, an diesen kannst Du ausprobieren, welche Reihenfolge Sinn ergibt. -- Mit Sirius' Post wäre das wohl geklärt ;)
Sirius3
User
Beiträge: 18253
Registriert: Sonntag 21. Oktober 2012, 17:20

Hier noch die Dekodierung der BASIC-Befehle, soweit im Beispiel vorhanden:
0x80: FOR
0xCB: =
0xBC: TO
0x87: PRINT
0x8B: NEXT
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Sirius3 hat geschrieben:läßt man von Deinen Daten die ersten 7 Bit weg, so kann ich immerhin den String "HELLO WORLD!" lesen.
Dann muß ich wohl quasi um 1bit "verrutscht" sein.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Toll! Ich sehe nun auch den "HELLO WORLD!" String aus den Daten, mit: https://github.com/jedie/python-code-sn ... _decode.py

Code: Alles auswählen

...
01000100 0x22  34 '"'
00010010 0x48  72 'H'
10100010 0x45  69 'E'
00110010 0x4c  76 'L'
00110010 0x4c  76 'L'
11110010 0x4f  79 'O'
00000100 0x20  32 ' '
11101010 0x57  87 'W'
11110010 0x4f  79 'O'
01001010 0x52  82 'R'
00110010 0x4c  76 'L'
00100010 0x44  68 'D'
10000100 0x21  33 '!'
01000100 0x22  34 '"'
...
Das "Verschoben" um 1 bit liegt IMHO daran:

Code: Alles auswählen

-    START_LEADER = "01010101"
+    START_LEADER = "10101010" 
Und das richtige Daten kommen daran, das die bit-Reihenfolge getauscht werden muß.


Danke euch allen!

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

jens hat geschrieben:Das ist auf meine Lücken im Basis-Wissen zurück zu führen.
Dann ist die Reihenfolge entscheident? Und auch wo "füll"-Bits hinkommen?
Ja, damit solltest du dich mal etwas genauer beschäftigen ;-) Ist nicht nur nützlich, sondern auch ganz interessant. Für diesen Fall reicht für dich aber wohl zu wissen, dass Binärzahlen, nichts anderes sind Bytes, sich genau so verhalten wie Dezimalzahlen.

Die Dezimalzahl 4567 hat den Wert 4*10³ + 5*10² + 6*10¹ + 7*10⁰. Bei Binärzahlen ist das nicht anders. Hier ist nur die Basis nicht mehr 10, sonder 2. Aus einer Binärzahl 100110 bekommst du den Wert in dezimalform: 1*2⁵ + 0*2⁴ + 0*2³ +1*2² + 1*2¹ + 0*2⁰.

Wenn du das Prinzip erstmal verstanden hast, dann ist der ganze Rest einfach. Bei der Endianness kommt es jetzt nur noch darauf an, wie die einzelnen Bytes angeordnet sind (wie sie im Speicher liegen), wenn mehrere Bytes einen Wert bilden. Angenommen, du hast einen Integer in binärer Darstellung aus 4 Bytes: ABCD. Das Bit ganz links in A hat die höchste Wertigkeit (2^32), das ganz rechts in D die kleinste (2^0). Bei Big Endian legst du A dann auf die Adresse n, B auf die Adresse n+1, C auf n+2 und D auf n+3. Im Prinzip kannst du die Zahl also noch ganz normal lesen. Bei Little Endian hingegen liegt D auf n, C auf n+1, B auf n+2 und A auf n+3. Die Reihenfolge der Bits in den einzelnen Bytes bleibt dabei erhalten. Warum es verschiedene Darstellungen gibt, dazu schaust du dir am besten den Wikipedia-Artikel an.

Ein Hinweis hätte ich auch noch: schau dir mal das struct-Modul an, das könnte hier hilfreich sein.
Das Leben ist wie ein Tennisball.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Hier mal in c-hackisch:

Code: Alles auswählen

from ctypes import c_ubyte

DATA = """<dein unpack-String von Einsen und Nullen des ersten Posts>"""

def iter_bits(s):
    for c in s:
        yield int(c, 2)

def reverse_char_bits(b):
    b = (b & 0xF0) >> 4 | (b & 0x0F) << 4
    b = (b & 0xCC) >> 2 | (b & 0x33) << 2
    b = (b & 0xAA) >> 1 | (b & 0x55) << 1
    return b

def convert(bits):
  sentinel = c_ubyte()
  i_bits = iter(bits)
  for bit in i_bits:
    sentinel.value <<= 1
    sentinel.value |= bit
    if sentinel.value == 42: # ?? nicht spec-konform
      break
  c = 0
  value = 0
  for bit in i_bits:
    if c == 8:
      yield chr(reverse_char_bits(value))
      c = 0
      value = 0
    value <<= 1
    value |= bit
    c += 1

bits = iter_bits(DATA.replace('\n', ''))
print ''.join(convert(bits))
Komisch ist das eine Bit, wodurch der Sentinel nicht 85 sondern 42 ist. Müsste man die Spec nochmal genau durchforsten.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Wie ich gerade gesehen hab, funktioniert mein aktueller code zwar mit der Datei "HelloWorld1 xroar.wav" aber nicht mit "HelloWorld1 origin.wav"

Das erste kam aus dem Xroar Emulator und das zweite hab ich vom Original selbst aufgenommen.

Komisch eigentlich, denn der "Syncronisierungs" Block wird in beiden Fällen gefunden.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten