Also, ja, scheint für 8000er zu sein, denn beim 4000er zerhaut es das layout. Anscheinend werden die 80 Zeichen vorausgesetzt.
Beiträge von auron
-
-
Platinenlayout? Das habe ich mit KiCAD gemacht. Und das Layout für den 3D-Druck in TinkerCAD. Aber das war nicht die Frage, oder?
Die Software ist für den Commodore PET, und war halt auf 8050er Disketten...
Ist eine SW für Bauingenieure, wohl die erste der Art in DE. Wie viel Stahlverstärkung brauche ich für Fundament X oder Brücke Y und sowas.
Da mir der Autor persönlich bekannt ist, werde ich sein Urheberrecht natürlich wahren, aber ich habe schon angefragt, ob das veröffentlicht werden kann.
Ich vermute keinen allzu großen kommerziellen Wert mehr, aber es könnte unter Umständen rechtliche Gründe geben, die dagegen sprechen. Oder er will einfach nicht, auch das würde ich akzeptieren.
Edit: und man merkt wie wenig ich in dem Thema PET drin bin.

Ob's speziell für den 8000er war weiss ich nicht. Ich probiere mal im Vice ob es auch mit ROM 2.0 geht. -
Noch mal aktueller Status für Interessierte:
Drei 30+ Jahre alte 8050 Disketten mit Ingenieurs-Statiksoftware erfolgreich eingelesen, und laufen auf Vice.
Drei weitere haben Fehler, da muss ich nochmal ran an meine Greaseweazle Patches, kann aber sein, dass die einfach defekt sind :-/
Aber die wichtigsten sind da, also vorerst mal

Danke an alle die mitgeholfen haben.
-
Zum Motor: das liegt ganz einfach an der Physik, oder genauer gesagt an der Steilheit der Windungen. Wenn der Originalmotor (mit der Originalspindel) eine volle Umdrehung macht, dann geht der Lesekopf um 2,65 mm vorwärts (das sind 10 tracks bei 96 TPI). Der Motor, den ich gewählt habe geht bei einer vollen Umdrehung viel weniger vorwärts, ich meine es sind 0,4mm, so dass ich bei 20 Vollschritten auf 0,02mm physische Ausflösung komme.
Bitte melde dich an, um diesen Anhang zu sehen.
Es sind also ca. 6 Umdrehungen auf dem kleinen Motor für jede Umdrehung auf dem Großen.
Ich dachte erstmal, man kann das ganze mit Microstepping hinbekommen, aber mehr als eine halbe oder maximal viertel physische Spur ist da nicht wirklich drin, weil wieder die Physik zuschlägt.
Beim Microstepping geht die Kraft herunter, mit der er auf den nächsten Microstep dreht. Das hat mich jetzt auch am Anfang verwirrt, weil es ja irgendwie "ging", das Problem ist die Präzision.
Beispiel: Nehmen wir an ich hab ein Vorderrad an einem Fahrrad. Das Fahrrad hängt an der Decke, ich kann das rad also frei bewegen. Um das Rad anzudrehen brauche ich eine gewisse Kraft X, um die Reibung im Lager zu überwinden, und die Masse zu beschleunigen. Zum Bremsen brauche ich eigentlich wieder die selbe Kraft (minus Reibungsverlust).
An dem Rad ist ein Schrittmotor, und der ist von der Kraft so dimensioniert, dass er seine 20 Vollschritte pro Umdrehung mit einer gewissen Geschwindigkeit hinbekommt, mit etwas Extrapower für leichte Verschmutzung und so.
Wenn ich das jetzt aufteile und jeden Vollschritt in 16 microsteps splitte, dann bekomme ich nur 1/16tel der Kraft pro microstep... (die Formel ist in Wahrheit komplizierter und exponentiell, aber für das Prinzip erstmal egal, siehe Bitte melde dich an, um diesen Link zu sehen.)
Jetzt mal in microstep gedacht: ich stehe an pos 0 und schalte auf 1. Auf mein Rad wirkt X/16 Kraft. Wenn mein System komplett lastfrei ist, dann dreht er vielleicht weiter, aber vielleicht ist die Reibung zu hoch und er macht nichts, oder wackelt nur etwas, bleibt aber auf pos 0.
Gut, ich schalte auf Step 2... Und hier kommt das fiese: Er summiert jetzt die Kraft von Microstep 1+ Microstep 2, weil er ja noch an pos0 ist. Wenn es langt, dann dreht er, sonst nicht.
Und so weiter, und so fort. Spätestens bei Microstep 16 hätte ich wieder die volle Nennkraft, und er dreht sicher einen Vollschritt weiter. In der Realität macht er es schon vorher.
Würde er bei 0->1 zufällig schon drehen, dann häte er für 1->2 natürlich wieder nur X/16 an Kraft zur Verfügung...
Ich weiss also nie, ob er jetzt wirklich weitergegangen ist, oder nicht, und ob er den "vollen" microstep gehüpft ist, oder nur ein bisschen, und dann in eine Reibungssperre gelaufen ist, und wie viele microsteps ich machen muss um ...
tldr: ich kann microsteppen, aber ich weiss nicht genau genug wo ich physisch hingesteppt bin.
Laut "dem Internet" geht halfsteps noch recht gut, und 1/4 step häufig auch...
Man kann den "kraftverlust" jetzt natürlich durch höheren Strom kompensieren, aber da läuft man Gefahr, den Rauch im Motor freizusetzen, und ohne den Rauch geht der Motor erfahrungsgemäß nicht mehr (Bitte melde dich an, um diesen Link zu sehen.)
Wenn ich mir jetzt mal die Signalqualität ansehe - du kannst es probieren...
Bitte melde dich an, um diesen Anhang zu sehen.
Die "Täler" sind das, was du treffen musst. Blau war glaube ich die Disk von Markus, grau die von Dir.
Die Punkte von links nach rechts sind jeweis 0,02mm, nach oben ist das Rauschen, kleine Werte sind also besser.
Nochmal etwas rechnen:
Das panasonic laufwerk, mit dem ich immer gebastelt habe, hat nativ 96 TPI, also 25,4mm/96 = 0.265mm. Speziell mein Floppy macht aber zwei physische steps pro track, hat also eigentlich eine native Auflösung von 0,132mm.
Nehmen wir mal an, 1/4 microstepping würde noch relativ zuverlässig gehen, dann habe ich 0,033mm, wenn ich nur halfsteps sauber hinbekomme, dann wären es 0,066mm.
Worst case ist ja in meinem Diagramm die Spur 0,6mm, mit 1/4 stepping sollte man das ausreichend genau treffen können, bei 1/2 habe ich Zweifel. Und wenn Dein Laufwerk die physischen Halftacks nicht macht, dann geht es sehr sicher nicht, weil 1/8 microstepping recht sicher zu viel ist, es sei denn du hast ein Floppy das 100% perfekt ausgerichtet, geschmiert, und überhaupt perfekt und ohne spiel verarbeitet ist. (imho unwahrscheinlich)
Ich werde mein Floppy allerdings glaube ich nicht mehr zurückbauen, um das zu testen, stehe aber gern mit Rat zur Seite.
Den Motor schicke ich gern per Post, deine Adresse hab ich glaube ich noch, sonst melde ich mich noch mal per mail.
-
Bei so super-einzigartigen Disketten wäre eventuell auch professionelle Hilfe angebracht.
In dem Video gibt es ein paar Hinweise auf was man achten sollte (und echt abgefahren die fehlenden Sektoren mit dem Speicheroszilloskop auszulesen)...
Bitte melde dich an, um dieses Medienelement zu sehen.
Mit GCR wird das oszi-auslesen aber vermutlich etwas kniffeliger, FM kennt ja nur 4 und 8 us, bei GCR sind's ja mehr Bänder.
Meine Floppy-mod ist bezüglich Diskettenschonung auch nicht ganz ungefährlich, weil man durch den Tausch des Steppers leicht den Anstellwinkel des Kopfes verändert.
Man muss also sehr genau aufpassen, dass man die Höhe über der Spindel wieder gut justiert.
Dazu hatte ich die Schraube auf dem Adapter eingeführt, die drückt die Mutter nach unten, so hat man da etwas handhabe.
Bitte melde dich an, um diesen Anhang zu sehen.
Wenn die Höhe nicht passt, ist der Kopf nicht parallel zur Floppy-Oberfläche, und dann schleift er "schöne" Rillen in die Disk.
Ich hab das bei mir exzessiv mit einer total unwichtigen Disk gestestet gehabt...
Bezüglich der Software: Eigentlich wollte ich da gerne noch etwas aufräumen, aber ich weiss nicht, ob und wann ich dazu komme...
Es ist alles reichlich zusammengeschustert
Arduino-firmware: Bitte melde dich an, um diesen Link zu sehen.
Gepatchtes Greaseweazle: Bitte melde dich an, um diesen Link zu sehen.
Gepatchte Greaseweazle Firmware: Bitte melde dich an, um diesen Link zu sehen.
-
So, andato77 : hier jetzt auch deine 8050 Demo Disk als Dump:
Bitte melde dich an, um diesen Link zu sehen.
Das geht jetzt echt schön, auf Anhieb alles drin. Er trifft jetzt sogar die tracks so sauber, dass er gar nicht mehr hin-und-her suchen muss.
-
Das bedeutet jetzt sieht es nicht mehr aus wie eine funkensprühende Trennscheibe sondern ist komplett grün?
:lol nein, leider bleibt die "Trennscheibe" im HxCFloppyEmulator sehr identisch, aber der Greaseweazle Dekoder hat alle Sektoren sauber gelesen. Soweit ich das beurteilen kann der G64-Dekoder von Markus auch.
Ich vermute dass das HxCFloppyEmulator entweder mit den Bitraten für die 8250 gar nicht klar kommt, oder aber ich einfach zu doof bin es zu bedienen.
Ich hab den raw Dump ja hochgeladen, bitte sehr gerne ausprobieren und "grün machen"

-
Köpfe gereinigt und noch kleinen Bug ausgebügelt.
Alle 4166 Sektoren erkannt

markusC64 hiermit ist auch mein Teil des Deals eingelöst

Bitte melde dich an, um diesen Link zu sehen. (12.7 MB zu groß für's Forum)
Und nur als Anmerkung:
Der Abstand zwischen den köpfen scheint genauso groß wie bei 96TPI Laufwerken zu sein, (+- 0.02mm) Der Offset ist jedenfalls für vorder und Rücksete der selbe.
Nur liegt der "Cylinder 0" (track1 und 78) jeweils 3 im "negativen" Bereich. Wo bei 96 TPI also Track 1 ist, liegt Track 4
-
Nochmal ein Zwischenstand:

sfd1001 Demo DiskCode
Alles anzeigenH. S: 012345678901234567890123456789012345678901234567890123456789012345678901234567 0. 0: ............................................................................ 0. 1: ............................................................................ 0. 2: ............................................................................ 0. 3: ............................................................................ 0. 4: ............................................................................ 0. 5: ............................................................................ 0. 6: ............................................................................ 0. 7: ............................................................................ 0. 8: ............................................................................ 0. 9: ............................................................................ 0.10: ............................................................................ 0.11: ............................................................................ 0.12: ............................................................................ 0.13: ............................................................................ 0.14: ............................................................................ 0.15: ............................................................................ 0.16: ............................................................................ 0.17: ............................................................................ 0.18: ............................................................................ 0.19: ............................................................................ 0.20: ............................................................................ 0.21: ............................................................................ 0.22: ............................................................................ 0.23: ................................................................ 0.24: ................................................................ 0.25: ..................................................... 0.26: ..................................................... 0.27: ....................................... 0.28: ....................................... 1. 0: X........................................................................... 1. 1: X.........................................................X................. 1. 2: X.........................................................X..X.............. 1. 3: X.........................................................X..X.............. 1. 4: X.........................................................X..X.............. 1. 5: X............................................................X.............. 1. 6: X........................................................................... 1. 7: X........................................................................... 1. 8: X........................................................................... 1. 9: X........................................................................... 1.10: X........................................................................... 1.11: X..............................................................X............ 1.12: X........................................................................... 1.13: X........................................................................... 1.14: X....................................................X...................... 1.15: X........................................................................... 1.16: X........................................................................... 1.17: X........................................................................... 1.18: X.............................................................X............X 1.19: X.......................................................X..X..X............. 1.20: X..........................................................X................ 1.21: X.............................................................X............. 1.22: X..........................................................................X 1.23: X............................................................... 1.24: X............................................................... 1.25: X.................................................... 1.26: X.................................................... 1.27: X...................................... 1.28: X...................................... Found 4073 sectors of 4120 (98%)Vielleicht muss ich meine Schreib-Leseköpfe nochmal etwas saubermachen...
Ist ja anscheinend nur die eine Seite...
HxC kommt damit nicht wirklich klar, aber vielleicht fehlen mir auch nr die Einstellungen
Bitte melde dich an, um diesen Anhang zu sehen.
Die Spiralförmige Anordnung finde ich aber bemerkenswert. Liegt das an der fehlenden Index-Orientieruung?
-
Die Flippy mod braucht man noch, weil der Floppy Controller sonst nicht in die negativen fährt.
Es gibt aber durchaus die Option, zumindest mit einem gepatchten greaseweazle, den Floppy Controller komplett zu umgehen, und die Steuerbefehle stattdessen direkt an den arduino zu senden. Dann bräuchte man die Flippy mod nur noch für die Hardware-Begrenzungen. Beim Panasonic muss man ja z.B. ein bisschen vom Rahmen wegdremeln, das wird natürlich nach wie vor nötig sein.Den arduino Code und die greaseweazle Patches möchte ich gern noch etwas aufräumen, bevor ich sie veröffentliche.
-
nicht viel...
paar Widerstände, Pufferkondensator, das TMC 2208 Reprap board und ein Arduino Nano.
Bitte melde dich an, um diesen Anhang zu sehen.
Dann brauchst du noch einen Schrittmotor der reinpasst, Zugriff auf einen 3D-Drucker und ein paar kleine Schrauben(M2, M1.4) und eine Mutter(M2).
Als Schrittmotor hab ich so einen hier aus Fernost via der Bucht:
Micro 5V 2-Phasen 4-Draht Schrittmotor Linearschraube 51mm Lang
Bitte melde dich an, um diesen Anhang zu sehen.
Ich hatte 5 gekauft, weil ich kein großes Vertrauen in die Qualität hatte, aber bisher läuft das ganz prima.
Ich kann Dir einen abtreten wenn du magst.
Die Connectoren waren etwas kniffelig - ich hab solche wie am Panasonic nicht gefunden und etwas hemdsärmelig einfach andere mit dem selben Rastermaß verwendet, und mit dem Cuttermesser entsprechend bearbeitet. Sorry, keine Ahnung mehr wo ich die herhatte. RM waren 2mm glaube ich.
Das Track0 Signal greife ich direkt vom Sensor ab, vor der Flippy-logik und dem Controllerboard. Das Controllerboard gibt das nicht 1:1 durch, sondern nur wenn es gerade Lust dazu hat...
Head input wird aktuell nicht verwendet.
-
Problem gefunden
In Greaseweazle ist bei gcr64 ein lowpass filter von 2.5us fix eingebaut...Wenn ich den auf 1.4 runterdrehe geht es
T6.0: Commodore GCR (29/29 sectors) from Raw Flux (242612 flux in 1021.36ms)

So, ich weiss also jetzt mit 15*0,02mm offset bin ich auf Track 6. Offset 2,3 wäre dann Track 5.
jetzt muss ich noch einbauen, dass er automatisch den Head-offset anpasst
-
Super, danke!
Leider bekomme ich rein gar nichts dekodiert.

Es lese nahe Track 1 (+- 5?), es sollte also eine Clock von 2.16us sein. Da mein Laufwerk aber mit 360 statt 300 RPM dreht werden das 1.8us
Ich würde nun die Bänder bei 1.8, 3.6 und 5.4 erwarten
Die heatmap sieht auf einem typischen Track-fragment(1ms) so aus: "[us]": [Anzahl]
Code
Alles anzeigen"1.7": 4, "1.8": 40, "1.9": 4, "2.0": 3, "2.3": 1, "3.3": 1, "3.4": 2, "3.5": 39, "3.6": 117, "3.7": 42, "3.8": 58, "5.1": 3, "5.2": 66, "5.3": 19, "5.4": 93aber häufiger so:
Code
Alles anzeigen"1.6": 1, "1.7": 6, "1.8": 67, "1.9": 9, "2.0": 5, "2.1": 3, "2.2": 1, "2.5": 1, "3.2": 1, "3.3": 1, "3.4": 6, "3.5": 40, "3.6": 25, "3.7": 57, "3.8": 31, "5.1": 3, "5.2": 35, "5.3": 8, "5.4": 1Die 1.8 sind ja meistens super-sauber, die 3.6 verschmiert gerne etwas, und die 5.4 wandert recht zuverlässig nach vorne Richtung 5.2.
Ist das so zu erwarten?
Wäre das jetzt etwas, was eigentlich funktionieren sollte, und ich hab vielleicht nur die Parameter nicht richtig gesetzt?
-
Greaseweazle kann die Disk-Definitionen intern abbilden.
Macht die Definition für 8250 so Sinn? (1571 zur Referenz)
Code
Alles anzeigendisk commodore.1571 cyls = 35 heads = 2 tracks 0-16 c64.gcr clock = 3.25 secs = 21 end tracks 17-23 c64.gcr clock = 3.50 secs = 19 end tracks 24-29 c64.gcr clock = 3.75 secs = 18 end tracks * c64.gcr clock = 4.00 secs = 17 end end disk commodore.8250 cyls = 77 heads = 2 tracks 0-32 c64.gcr clock = 2.16 #3.25 * 16 /24 secs = 21 end tracks 33-46 c64.gcr clock = 2.33 #3.50 * 16 /24 secs = 19 end tracks 47-58 c64.gcr clock = 2.50 #3.75 * 16 /24 secs = 18 end tracks * c64.gcr clock = 2.66 #4.00 * 16 /24 secs = 17 end endWie gesagt, hauptsächlich um die Track--Nummer extrahieren zu können. Ich bin ganz bei Markus, dass ein Archive dump immer besser ist.
-
Es gibt durchaus Disketten, die öfter Lesefehler produzieren, aber nicht immer. Da ist also schon ein wiederholter Leseversuch ohne die Kopfposition zu ändern derartig, dass die eingelesenen Daten sich signifikant verändern
Und hier frage ich mich, woran das eigentlich liegt. Die magnetischen Domänen sind ja wohl immer da, oder halt nicht, nur manchmal wird der flux-change erkannt, und manchmal nicht.
Ich würde jetzt drauf tippen, dass der "Rand" der magnetischen domäne irgendwie unscharf ist, und damit der Strom-Spike im Lesekopf nicht mehr steil genug ist.
In dem Fall könnte eine x-tel Spur hin oder her schon einen Unterschied machen, wenn da das Medium noch sauber ist.
Oder wenn eine Spur / ein Sektor mit einer anderen Floppy geschrieben wurde, die leicht anders kalibriert war.
Ich könnte klar immer drei versionen vom Track schreiben, viertel vor, punkt und viertal nach - was ich gerne umgehen würde ist, die Flux zusammenrechnen zu müssen. Beim Index auseinandernehmen und zusammensetzen funktioniert für die GCR Disks vermutlich nicht so gut, weil die nicht am Index orientiert sind. Ich müsste also dann Logik implementieren um rauszufinden wo die Drehung aufhört.
Oder ich steppe einfach unter dem Lesen, aber das wird mit dem timing schwer. mal schauen.
-
Außerdem ist es bestimmt nützlich, die original 1541 Hardware nachgebaut zu haben im Decoder
Ah, das hab ich jetzt erst beim nochmal drüberlesen verstanden. Du hast also die Original-Hardware in einer .net DLL emuliert/nachgebaut? Cool

-
Ja, dass die 8250 die Bitcellsize um genau den Faktor 16/24 gegenüber einer 1541 hat.
16/24 ist ja irgendwie 2/3
OK, trotzdem eine krumme Zahl...Greaseweazle hat intern schon die Funktion den Flux umzurechnen für unterschiedliche RPM Werte. Wenn ich also auf 3/2 => 150% gehe, müsste ich mit der Bitcellsize ja wieder auf dem Standard liegen.
Probiere ich nachher mal aus.
-
Wenn Du magst, kannst Du mein in Entwicklung befindliches Tool zum Dekodieren versuchen. Das ist erheblich schneller als g64conv. Auch wenn es noch Feature incomplete ist, den Teil bekommt es derzeit schon hin, denke ich.
Gern, aber das war, wenn ich mich recht erinnere, in Perl. Das würde bedeuten, dass ich eine Datei schreiben und einen System-Call aus dem Python heraus machen muss.
Ich würde es mal mit dem integrierten GCR decoder probieren, viellicht bekommt der ja einen Sektor-header decodiert. Brauche ja nur einmal den Track.
Ich bin da vielleicht naiv, aber gibt es so große Unterschiede in den GCR codierungen? Hier hab ich jetzt erstmal nichts entsprechendes gesehen.
[ Bitte melde dich an, um diesen Link zu sehen. ]
-
Würde es nicht Sinn machen zusätzlich einen Recovery Modus zu haben wo man bei bekanntem Diskformat eine Spur dreimal eingelesen wird, einmal mittig, einmal etwas weiter und einmal etwas zurück vom Optimium, diese 3 Leseversuche werden dann synchronisiert und wenn ein Flußwechsel bei zweien gleich ist wird diese Version genommen und der 3 Variante ignoriert.
Interessant wäre dann natürlich eine Statistik wie oft jede Variante eintrifft und ob wohlmöglich auch mal Optimaler Track hat Fehler aber beide etwas daneben Leseversuche nicht vorkommt.
Das müßte auch bei unbekanntem Format funktionieren aber bei bekanntem Format kann man evtl. noch per CRC auf valide oder nicht testen.Ja, das hatte ich schon geplant. Wenn der eingelesene Flux grob vom erwarteten Noise-level abweicht (oder optional wenn der decoder Fehler wirft), würde ich nochmal etwas links und rechts probieren.
Das war meine erste implementierung, aber dann hat er auf einmal mehr oder weniger jeden Track versucht zu optimieren, und ist dabei auch übers Ziel hinausgeschossen und hat dann den Nachbartrack 2x gelesen...
-
Nochmal ein Zwischenstand:
Ich habe die GW-Firmware etwas gepatched, um mehr als 100 Cylinder anfahren zu können ( noch nicht sicher ob wirklich notwendig), und auch das GW Python frontend, damit es mit meinem Hardware-Mod kommunizieren kann.
Ich habe auch die Histogramm-Idee umgesetzt, und das liefert wirklich schöne Werte.
Bitte melde dich an, um diesen Anhang zu sehen.
Verschiedene Disks, reichlich durcheinander, mal runterbrechen...
Nach oben ist der "noise-level", nach rechts der 0.02mm offset von meinem "norm-0"
Mein Norm-0 ist nach dem Hardware-mod sehr sicher nicht gut on-track, es ist nur das wo ich gegen meinen track-0 sensor kalibriere.
Die Werte sind leicht geglättet (moving average über 3 offsets), für die weitere Betrachtung ist das glaube ich belanglos.
Was man sehen kann ist, dass die verschiednenen Formate sich anscheinend nicht auf einen einheitlichen track-center einig sind, und dass offenbar der Noise-Level zwischen den Tracks mit der TPI-Zahl massiv abnimmt...
1) Positioniergnauigkeit
Bitte melde dich an, um diesen Anhang zu sehen.
Mal nur eine 96 TPI disk und eine 48 TPI Disk, mehrfach gelesen, auch mit Diskettenwechsel.
Man sieht sehr schön, dass der Hardware-mod erstaunlich präzise ist ( repeatability ), ich würde schon fast sagen, perfekt.
Auch auffällig: bei 48 und 96 TPI hätte ich erwartet, dass die Noise-Spikes (also das wo man zwischen den Tracks ist) an den selben Stellen sind, nur bei 96 TPI doppelt so häufig.
Mein Laufwerk würde ich als Fehlerquelle mal ausschließen, wegen der Wiederholbarkeit. Auch wenn ich off-track bin, sollten die Graphen um den selben Wert verschoben sein.
2) verschiedene Disks
Bitte melde dich an, um diesen Anhang zu sehen.
grün und grau sind die selbe Disk, mit diskwechsel 2-mal gelesen. Rot eine andere 96 TPI disk. (vermutlich mit dem selben Quelllaufwerk geschrieben)
Passt soweit, würde ich sagen.
3) 100 TPI
Bitte melde dich an, um diesen Anhang zu sehen.
Blau ist die SFD1001 Disk von Markus, Grau die 8050 Testdisk von Andato77
Bei der 8050 scheint es wichtiger zu sein, exakt on-track zu sein, denn die Täler sind zum Teil recht eng. Die beiden Laufwerke scheinen sich aber relativ einig zu sein wo der track-center ist.
To-Do:
a) Track-center tuning programmieren ( relativ trivial )
b) herausfinden, welcher Track eigentlich gerade center ist, ich könnte jetzt einen oder mehrere daneben liegen. (dazu muss ich decodieren und in die header schauen - geht hoffentlich mit den GW-integrierten decodern)
c) alles noch aufräumen - im Moment ist es ein ziemliches gehacke..
Edit: Typo