Wäre eine super Sache., wenn dies klappt
Also ich werde ih n euch definitv nicht wegschnappen.

Nicht nur,weil ch schon einen habe, sondern vorallem auch,weil ich ja auch sehr intressiert an dem Gelingen des Projektes bin

Moin,

kurzer News-Letter:

- ich werde einen Artikel fuer das amerikanische "Linux Journal" schreiben und hoffe, somit noch mehr Unterstuetzer weltweit zu finden; ich habe gerade mit einen der Redakteure im IRC geredet (die haben nen eigenen Channel ) und der hat mich ermutigt, etwas einzusenden; sie nehmen gerne Artikel von Privatleuten

EDIT: Hier der Brief, den ich an das Linux Journal geschrieben habe: http://paste.lisp.org/display/80570

- im MDCF kommen langsam auch immer mehr Interessenten zusammen und die Spendenbereitschaft steigt, wir sind bereits bei 60 Euro; Hannes hat noch einmal 10 Euro springen lassen und mehrere Leute im MDCF-Forum haben gespendet oder Spenden zugesagt

- der Thread im MDCF wird auch immer laenger, siehe hier: http://forums.minidisc.org/index.php?showtopic=22333&st=0

- unser harter Kern von Entwicklern (3 Leute) arbeiten fieberhaft an OpenMG; es werden disassembler und Code-Analyzer fuer die OCM-Dateien geschrieben und der Code wird immer weiter aufgedeckt und die Verschluesselung verstanden; das Wiki erhaelt fast taeglich dazu neue Informationen

- mannermoe versucht gerade QHiMDTransfer unter Windows zu bauen; er versucht dazu ganz Qt noch einmal mit CygWin zu uebersetzen. Wir werden aber libhimd und QHiMDTransfer wohl nach minigw portieren. Dieser Compiler erzeugt Windows-Executables, die keiner weiteren DLLs zur Laufzeit benoetigen (CygWin-Programme brauchen zur Laufzeit immer CygWin)

- naechste geplante Implementationen in libhimd/QHiMDTransfer: automatische Umwandlung von RAW-PCM nach WAV; Upload von verschluesselten PCMs und ATRAC-Dateien (alles was "himdtest" mit non-zero key anzeigt)


So, mehr faellt mir grad nicht ein .

Adrian

Kann ich machen, kein Problem.

Super, ich bin schon dabei, auf das Teil zu bieten. Das Gehaeuse hat eh ne kleine Delle, is daher wahrscheinlich fuer echte Sammler uninteressant . Waer schoen wenns klappt.


Ach ja, ich komme mit dem Projekt uebrigens ins Linux Journal .

EDIT: Fast 70 Euro Spenden.

Adrian

Der verschickt den RH1 auch, siehe Frage/Antwort-Bereich im Angebot.

Schon gesehen. Bin auch ueberboten worden und biete jetzt auf ein japanisches Modell aus den USA. Ma guggen .


Adrian

Moin,

so, dank Umstellung auf CMake konnte nun auch eine Windows-Version gebaut werden, bitte um Tester:

http://users.physik.fu-berlin.de/~glaubitz/linux-minidisc/qhimd-win.zip

EDIT: Version fuer Windows durch jene ersetzt, die mannermoe freundlicherweise kompiliert und getestet hat. Ich hab leider kein Windows zum Testen da, ich hab da in einer virtuellen Windows-Umgebung gebaut.

Adrian

Super Sache
Damit wird QHimdTransfer auch für die ganzen Windows-Nutzer eine Sonicstage-Altrernative,zumindest für HiMD
Ist das Übertragen von MP3 von PC auf MD auch schon drin?

Die Windows-Version funktioniert gut.
Wenn man bei Connect einen falschen Pfad eingibt stürzt QHiMDTransfer ab, aber damit kann man vorerst leben.

Die libgthread, libgobject, libgmodule, libgio und intl dlls werden nicht gebraucht bei der Windows-Version, die ich selbst gebaut habe.
Jedenfalls funktioniert alles (MD formatieren noch nicht getestet) ohne daß er wegen fehlender dlls meckert.

Ich habe mir gestern mal ´ne kleine Batchdatei gebastelt welche mit himdtest die Tracks von einer HiMD ausliest und an mplayer (bzw. sox und dann mplayer bei pcm) weitergibt.
Vielleicht könnte man sowas noch in QHiMDTransfer einbauen.
Ein "Play"-Button der den ausgewählten Track an Mplayer bzw. den eingestellten Standard-Player weiterleitet.

Das ist bekannt, ich hatte bisher keine Zeit das zu fixen. Das sollte ein Zweizeiler sein, aber man muss vorher die Qt-Doku lesen. Wie gesagt, Diplomarbeit und ich muss mich auf ne Konferenz vorbereiten.

Bugs und TODO siehe hier:

https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php?id=qhimdtransfer#todo



Du darfst deine Version gerne veroeffentlichen. Uebrigens kommt das Command Prompt Fenster daher, dass QHiMDTransfer mit Debug-Optionen uebersetzt wurde. Man kann das abdrehen, aber ich hab noch nicht nachgesehen. Das macht man mit dem Qt-Creator. Probier einfach mal rum.



Formatierung einer HiMD funktioniert derzeit nur mit dem Tool "himdformat", welches im Ordner basictools liegt. Das Tool benoetigt derzeit die Linux SCSI-Library und funktioniert deshalb nicht unter Windows. Format hat derzeit keine Prioritaet, aber wird kommen. Wir muessen "himdformat" dazu auf libschily bzw. libusal (beides portable SCSI-Libraries) portieren, dann wird QHiMDTransfer auch formatieren koennen.



Nee, also QHiMDTransfer soll ein reines Transfertool bleiben. Es steht dir natuerlich absolut frei, QHiMDTransfer im Quellcode deinen Beduerfnissen anzupassen oder gar einen Ersatz zu schreiben, welcher auf libhimd aufsetzt. Eine GUI mit Visual C++ zusammenzuklicken dauert auch nicht lange, sollte eine Sache von ein paar Stunden sein. Delphi koennte auch klappen, da man ja gegen C-Code linken kann.

Ihr seid alle aufgefordert mit dem Quellcode herumzuspielen und Verbesserungen einzubauen, Patches nehme ich gerne entgegen.


Adrian

So, eure Version funktioniert auch ohne die besagten dlls.
Beim Test mit dem Mixedmode-MD Image bekomme ich allerdings beim mp3-Upload folgenden Fehler:
Error opening track 3: Can´t open mp3 track: Compiled without mad library

Dementsprechend hat die erzeugte mp3 ein Größe von 0.
@adrian: Ich schick dir mal meine Version, ist als Anhang hier zu groß.

Für alle "Windows"er die´s interessiert:
Der Anhang ist meine Batchdatei, sollte unter Windows ab 2000 funktionieren.
Ist zwar nicht ganz fehlerfrei, aber ist ja auch erstmal nur zum Testen.
Unterstützt werden nur mp3 und unverschlüsselte pcm.
Die Win32-Versionen von MPlayer und sox werden benötigt.
Dazu entweder den Path erweitern, damit sie gefunden werden oder ins QHiMDTransfer
Verzeichnis entpacken.
Die playmd.bat ins QHiMDTransfer Verzeichnis entpacken und durch Doppelklick starten.
pcm-Wiedergabe kann etwas länger dauern.

Wir haben soeben einen freiwilligen gefunden, der sich um die Windows-Ports kuemmert .


Adrian

Yep, kein Problem (jedenfalls bis jetzt noch nicht )

Nope, ich hab jetzt die release gebaut -> genau das gleiche
"Run in Terminal" ist auch abgeschaltet.
Ich begebe mich dann mal auf die Suche ...

edit: Fehlmeldung: hat doch nicht geklappt mit der release, ist immernoch die debug-Version

Bitte probier mal die Software ohne die gdb-marcos zu bauen. Also, einfach aus dem Makefile die Dateien *gdb*.cpp auskommentieren, dann solltest du eine non-debug Version erhalten.

Adrian

Die gdb-macros find in der neuen Version doch garnicht mehr drin.
cmake gibt mir auch keine Auswahl zwichen debug und release, es gibt nur ne all.
Wenn ich per qmake -config release die Makefiles erstellen will meckert er schon daß die gdb-makros nicht da sind.
cmake-Version auf Ubuntu intrepid öffnet kein Terminal wenn ich´s über Dolphin öffne.
Müsste also an der Windows-Protierung liegen und nicht an der debug-Option.

Moin,

so, QHiMDTransfer erzeugt jetzt direkt WAV-Dateien aus den Raw PCM-Daten vom MZ-RH1, dank libsox.

Zum Testen neuesten Code ausm git pullen und bauen.

@mannermoe: Bitte neue Windows-Version fuer die Windows -User, wenn du Zeit und Lust hast .

Adrian

Ist in Arbeit, ich muß mir nur erstmal sox und sox-devel für MinGW basteln, der wehrt sich noch
Die downloadbaren Sox Windows binaries basieren nämlich auf cygwin und sox-devels gibt´s auch nicht dafür.

mfg mannermoe

P.S.: Ich habe auch gerade mein erstes Programm in C geschrieben (Irgendwann muss ich ja mal anfangen C zu lernen ).
Aus aktuellem Anlaß : pcm2wav
Das ganze zwar noch "unluxuriös", d.h. es braucht/akzeptiert keine Parameter.
Es sucht im akt. Verzeichnis nach einer stream.pcm und konvertiert diese in eine stream.wav.
Ist stream.pcm nicht vorhanden wird abgebrochen, existiert stream.wav schon kann man auswählen ob überschrieben oder abgebrochen wird.
Also, wer´s testen möchte.
Bauen mit "g++ -Wall -o pcm2wav pcm2wav.c" ("g++ -Wall -o pcm2wav.exe pcm2wav.c" für Windows), habe es bisher nur unter Windows getestet.
Sollte "pcm2wav.c:58: warning: statement has no effect" auftauchen, einfach ignorieren, da irrt sich der Compiler, der Code ist schon richtig so .
Im Anhang ist der Soucecode und die Windows binary.

Hallo,

jetzt gehts so langsam an die ersten Gehversuche zum MP3-Download. Dafuer brauchen wir vorher ein paar Tests. Und zwar wollen wir herausfinden, ob eine Fragmentierung der Audiodaten moeglich ist oder SonicStage einfach Loecher in dem Containerfile laesst.

Erklaerung:

Angenommen, wir speichern 3 MP3s auf eine frisch formatierte HiMD. Danach loeschen wir MP3 Nr. 2 und erhalten somit ein Loch im Datenfile. Wenn wir nun eine neue, groessere MP3 auf diese HiMD speichern, was genau passiert dann ? Zerlegt SonicStage die neue MP3 in Fragmente und packt einen Teil ins Loch und den Rest hinter die urspruengliche MP3 Nr. 3 oder packt SonicStage die gesamte neue MP3 ans Ende hinter Nr. 3 ?

Zum Testen:

1. SonicStage starten, HiMD formatieren und 3 MP3s auf die HiMD laden, danach mit "himdtest /mnt tracks verbose" Inhalt anzeigen lassen
2. MP3 Nr. 2 loeschen und erneut "himtest /mnt tracks verbose"
3. MP3, welche groesser als MP3 Nr. 2 ist auf die HiMD laden und erneut "himdtest /mnt tracks verbose"
4. 1. und 2. wiederholen, jetzt jedoch eine kleinere MP3 als Nr. 2 aufspielen und erneut "himdtest /mnt tracks verbose"

Wir brauchen jeweils die komplette Ausgabe von "himdtest". "/mnt" muesst ihr natuerlich entsprechend anpassen, je nachdem, wo euer HIMD-Walkman gemountet wurde (unter Windows ist dies natuerlich ein Laufwerksbuchstabe).

Ich hab grad kein USB-Kabel da zum Testen. Falls jemand das mal schnell machen koennte, waer das sehr hilfreich.

Edit: Windows-Version von mannermoe: http://users.physik.fu-berlin.de/~glaubitz/linux-minidisc/QHiMDTransfer-win32-20090601.rar
Edit2: Danke auch fuer den MP3-Test, mannermoe. Siehe: https://wiki.physik.fu-berlin.de/linux-minidisc/doku.php?id=himddiskformat#fragmentation (non public)

Adrian

äh, wie lest ihr denn die atdata.hma? low level per sektoradressierung, oder high-level per "open file as binary" über die system-api

sprih, spielt es eine rolle,auf welchen sektoren die datei liegt,oder nur, wie innerhalb der datei selbst die daten liegen?

und wie liest der himd-rekorder sie?