http://satellite-board.de

Prinzipiell sieht der Code schonmal gut aus, aber auch so wirst du nicht über die 2GB kommen, da du die SetFilePointer API nicht voll ausnutzt

Hier ist die MSDN SetFilePointer API Beschreibung. Die ist zwar in C++, aber prinzipiell wird die API in Delphi ja genauso angesprochen.


Du nutzt nur "lDistanceToMove". Damit kannst du aber nur 2GB ansprechen. Willst du über die 2GB Grenze mußt du auch "lpDistanceToMoveHigh" verwenden.


Nee, das hat mit ASCII nix zu tun. Schon mal was von einem Byte gehört ?!
Bytes sind prinzipiell Integerwerte im Bereich von 0-255 (0x0-0xFF)

Der American Standard Code for Information Interchange (landläufig auch ASCII genannt ) nutzt zwar ebenfalls 256 Werte, aber du mußt nicht das ASCII Zeichen selbst betrachten, sondern den Zahlenwert als solches

Was bedeuten die Werte der Struct? Nun ganz einfach:
char = 1 Byte = buffer[x] = 0-255
int 8 = 1 Byte = buffer[x] = 0-255
int16 = 2 Byte = buffer[x]*256+buffer[x+1] = 0-65535

okay werde code korigieren

Nee, das hat mit ASCII nix zu tun. Schon mal was von einem Byte gehört ?!

ja clar o-255 = 1byte = 8bits in delphi gibs ja eben die funtionen

inttohex usw.

int16 = 2 Byte = buffer[x]*256+buffer[x+1] = 0-65535
jetzt weiss ich auch warum bei mir das jahr verkert dargestellt wurde .-)

zu int16 iVideoFatEntry
werte ich den wert so aus wie buffer[x]*256+buffer[x+1] = 0-65535
der wert als solches ist das das ? byte in der fat?
oder inttostr(buffer[84])+inttostr(buffer[85]) byte in fat?

wie ich eben an die werte rankomme ist klar aber auf welche art und weisse die werte verwendet werden ist mir noch unklar

Was willst du mit IntToStr? Ich sagt doch bereits, daß du da nichts mit ASCII Werten bzw. Strings anfängst.

Also Berechnung der Integer/Byte Werte.

Anmerkung: Es kann allerdings auch sein, daß du den int16 Typ nach folgender Formel berechnen mußt: buffer[x]+buffer[x+1]*256 (sprich nicht das erste Byte mit 256 multiplizieren, sondern das 2. Byte) Das hängt davon ab, ob das FileSystem BigEndian oder LittleEndian ist.
Einfach mal ausprobieren, laut Beschreibung des Filesystem sollte es aber Byte1+Byte2*256 sein.

[B]
Wie du die Werte verwendest mußt du selber herrausfinden, ich hab schließlich nicht den Inhalt deiner Festplatte hier. Ich hab auch nicht vor dir den kompletten Code zu entwickeln

Nur als Tip: du gehst einfach mal nach methodischen Grundlagen vor:
1.)
lösche die komplette Festplatte, in dem du 0x00 Bytes drauf schreibst

2.)
mache im Receiver exakt eine(!) einzige Aufnahme

3.)
lese die FileDescription aus

4.)
anhand der Einträge in der FileDescription iVideoFatEntry und iAudioFatEntry Pointer berechnen

5.)
mit diesen Pointern den entsprechenden FAT Eintrag suchen (laut Einweisung ist 1 FAT Eintrag = 4 Bytes)

6.)
die ersten beiden Bytes diese FAT Eintrages auswerten und schauen wohin die genau verweisen (das mußt du selber nachschauen, denn ich hab ja keine Hyundai Platte im Rechner zum auslesen)



Anhand diese FAT Einträge wirst du irgendwo hin verwiesen, wo du dann eine Abfolge von Bytes finden wirst


Für die erste Aufnahme muß das erste Byte für den Video Cluster 1 sein (bzw Cluster 2 für den ersten Audio Cluster). Die nachfolgenden Bytes in diesen Einträgen sind dann die nachfolgenden vom Video oder Audio belegten Clusternummern.

Als Beispiel:
Für die Liste der belegten Video Cluster bekommst du wahrscheinlich solche Werte:
01 03 04 05 06 .. 2E 2F 30 00 00 00 usw.
Das bedeutet Cluster Nummer 1, 3, 4.. bis Cluster 30 sind Video Cluster (die nachfolgenden 0x00 Bytes zeigen keine Cluster mehr an!)

Und für Liste der Audio Cluster könnte es so aussehen:
02 10 1D 00 00 00
Dann wären Cluster 2, 0x10, 0x1D die Audio Cluster der Aufnahme (auch hier gilt 0x00 Bytes zeigen nicht auf Cluster!)

Dann hast du eine Liste mit allen Clustern einer Aufnahme, die jeweils zu einem Video Stream und einem Audio Stream gehören und du kannst diese Streams in zwei separate Dateien rippen.

ja die inttostr funktion hab ich nur genommen um die einzelnen bytes ins edit zu laden um zu überprüffen ob werte richtig geladen werden
die werte werden auch richtig zu geladen

Wie du die Werte verwendest mußt du selber herrausfinden, ich hab schließlich nicht den Inhalt deiner Festplatte hier. Ich hab auch nicht vor dir den kompletten Code zu entwickeln

<--- das solltst du ja auch nicht das ist schliesslich mein part

hab versucht nach deiner formel die jehreszahl zu berechnen
aber die stimmt dann nicht
ich komme auf einen falschen wert
hier mal die byte werte byte1 = 21
byte2 = 27
das jahr ist 2004 und solange ich nicht an das korecte jahr komme hab ich auch nur müll bei __int16 iVideoFatEntry;
__int16 iAudioFatEntry;

da die ja auch von int16 sind

okay also werden von iVideoFatEntry die bytes als solches verwendet dementsprechend ist ja byte = 1 der erste cluster

und vielen vielen dank für deine geduld und ausfühliche hilfe

Hast du die richtigen Bytes aus dem Buffer genommen?

int8 iRecordNo =1 Byte
char cStationName[0xE] = 14 Bytes
char cClipName[0x29] = 41 Bytes
1+14+41=56 bereits belegte Bytes -> also erst ab der Array Position 57 kommt iRecordYear mit 2 Bytes.


->buffer[57]+([58]*256)

2004 in Hexadezimal sind 0x7D4

->Byte1 = 0xD4 = 212
->Byte2 = 0x7 = 7

iRecordYear=Byte1+(Byte2*256)=212 + (7*256) = 212 + 1792 = 2004


Ein weiterer Tip: versuche nicht alles zu konvertieren, um die Werte in irgendwelchen Memos oder Textboxen zu sehen.
Wenn du einmal aus Versehen falsch konvertierst oder Werte an den falschen Stellen suchst wirst du immer wieder durch die falsch angezeigten Werte nach Fehlern suchen, die keine sind.
Gehe besser hin und speicher mal die zu untersuchenden Sektoren als Binary (z.B. als Datei "Sector.bin") auf die Festplatte und öffne den gespeicherten Sektor mit einem gutem Hexeditor. Der Hexeditor zeigt dir auf jeden Fall korrekte Werte an und du brauchst nicht für jeden neuen Wert, deine Anzeige Routine umzuschreiben.
Das hat auch noch einen weiteren Vorteil. Wenn du weißt, daß ein gewisser Wert irgendwo auftauchen mußt und du ihn durch deine eigene Anzeige nicht siehst, weil du an der falschen Stelle suchst, kannst du im Hexeditor trotzdem schnell überblicken an welcher richtigen Stelle sonst der Wert zu finden ist.

hab meinen code überprüft

hast recht gehab ich hate ein verschiebung im array
jetzt wird auch das jahr korect wiedergegeben

erster videocluster bei 1
erster audiocluster bei 2
vorher lagen die bei 10 und 20

na dann, ich glaub den fehler hätt ich nie gefunden dann vielen
dank vieleicht schaust du öfters mal vorbei in diesem thread
fals ich noch ein par fragen habe ,ich glaub jetzt weiss ich genug um alleine weiter zu machen.

achso woher weiss ich über wieviele cluster sich die video oder audio -dateien ertrecken von einen film ?

wie weit bist du mit dein prog ?

Es gibt keinen Eintrag wieviele Cluster genutzt werden, sondern du mußt alle Cluster erstmal selber auflisten.
Ich weis es zwar jetzt nicht wie genau das im FileSystem aufgebaut war, aber da wo du die erste Clusternummer ausgelesen hast (also die 0x1 und die 0x2) findest du entweder einen weiteren Verweis auf den nächsten FAT Eintrag mit Clusternummer oder direkt die nächste Clusternummer. Die mußt du halt fortlaufen auslesen wie ich es oben beschrieben hab. Erst wenn du alle Cluster in einer Liste zusammengetragen hast kannst du auch genau sagen wieviele es sind

[B]
Irgendwas zwischen Alpha Stadium und einer Beta Version, weil der DigiCorder ein komplett anderes FileSystem hat wie z.B. der Hyundai und ich in letzter Zeit ganz andere Sachen gecodet hab.
Wenn ich im Herbst mehr Zeit kriege setze ich mich da wieder ran

Sorry, wenn ich euch Wasser in den Wein gieße

Die Idee, MPEG-Aufzeichnungen wieder auf die Recv-Platte zu schreiben, ist schon recht alt. Versuche, das zu realisieren sind ebenso alt - und leider erfolglos.

Andal (neben Boom Autor von WinPVR) hat versucht, gerippte Daten wieder auf die HD zu schreiben. Es ist nicht gelungen. Die vorhandenen und zum Rippen ausreichenden Informationen über die Datenstrukturen sind offenbar unvollständig.

Eure Diskussion über Details ist sehr eindrucksvoll. Um mehr darüber zu sagen/schreiben, müsste ich sie auch verstehen
Ich kann mir vorstellen, dass Andal auf Anfrage den Source-Code zu WinPVR heraus gibt. Probier es doch einmal. Seine Adresse steht am Ende von http://www.radonmaster.de/pvr-ripper/

Trotzdem viel Erfolg!

hallo robernd

habe andal perr e-mail kontaktiert zwecks sourcecode
bin ja gespannt ob er den code mir gibt, ich mach mir da aber nicht so viel hoffnung
mal ehrlich wer so viel arbeit reinsteckt wer gibt da schon den
code frei.
aber danke für dein tip versuchen kann man es ja
und code versteht mann ja die zusammenhänge doch besser
sollte andale den code freigeben na dann vieleicht wirds ja dann
ein opensource project und es entwickelt sich ein richtiges Mamutprogramm wär doch super oder ?

http://www.hdtforum.de/viewtopic.php?t=4427

moin moin....

keine Ahnung wie der letzte Stand ist ... aber Andal hat ja die Sources auch von Boomer (dem Schöpfer:D ) und der hat ja auch wegen der Weiterentwicklung die Sorces weitergegeben.


Leo

Hi,
entschuldigung, dass ich hier lange nicht mehr hereingeschaut habe. Mir fehlte einfach die Zeit.

Der letzte Stand zu Andal und WinPVR:
1. Andal hat die Version 1.0 von seinem Programm fertiggestellt. Ich hatte nur noch keine Zeit, sie ins Netz zu setzen.
2. Andal wird an WinPVR nicht weiter entwickeln.
3. Andal hat deshalb die Source freigegeben. Auch diese soll auf meine HP - Aber die Zeit

Danke Andal !

Nachtrag: Ich habe die neue WinPVR-Version gerade in einer Hau-Ruck-Aktion ins Netz gesetzt. Übersetzte Version und Source stecken im gleichen ZIP-File. Ursprünglich wollte ich beide trennen, damit sie etwas handlicher werden.
http://www.radonmaster.de/pvr-ripper/