http://satellite-board.de

hallo
habe gelesen das die autoren hier die entwickler für WinPVR
sind?
auf http://www.radonmaster.de/pvr-ripper/

häte da mal ne frage an diese autoren hier und zwar?
ich möchte ein tool schreiben um um vcd oder svcd dateien auf festplatte zu speichern um sie über den reciver abspielen zu können.
würdet ihr mir mit ein bischen theorie unterstützen ?
ich müsste wissen in welchen format die dateien vorliegen.
und häte da noch ein paar andere fragen.

Ich bin zwar nicht der Coder vom Hyundai Ripper, aber ich kann dir sagen, daß es eine kleine Aufstellung des FileSystems gibt:
http://www.radonmaster.de/pvr-ripper/einw.html

Das Format der gespeicherten Dateien war glaube ich MPEG-TS (TS=Transportstream -> 1 TS Paket = 188 Bytes = 4 Bytes Header + 184 Bytes Payload an Daten).
Genaueres sollte in der ISO IEC13818 stehen.

das ist doch schon mal was aber leider reicht mir das nicht ;-(
so wie ich das bisher sehe liegen die files als mpeg2 vor
nur eben keinen zugriff unter win98 durch api-function.

habe gelesen das winxp ne api-function bereit stellt ,würde mir diese der autor veraten ???? deswegen wird wohl winpvr erst ab winxp laufen

Es gibt mehrere Möglichkeiten auf eine Festplatte zuzugreifen.

Unter der Windows NT Schiene (NT, 2000, XP) geht das mit folgenden API´s
-CreateFile
-ReadFile
-WriteFile
-CloseHandle
Als Filename für diese APIs nimmt man entweder den Laufwerksbuchstaben oder die physikalische Laufwerksbezeichnung z.B. PhysicalDrive0 etc.

Unter Windows 9x (95, 98, ME) geht das mit den gleichen APIs, aber der Zugriff erfolgt nicht über den direkten Laufwerksbuchstaben, sondern über eine Windows VXD "VWIN32". Dazu dürfte sich bei Google einiges finden lassen. Zusätzliches Stichwort "INT13".

Diese Routinen lassen sich prinzipiell in jeder Standardprogrammiersprache umsetzen, ich hab allerdings die Erfahrung gemacht, daß VB von der Geschwindigkeit des Rippens her wesentlich langsamer ist als z.B. Delphi oder C++.

super danke für deine antwort
hab biss jetzt einen zugriff aus die einzelnen cluster der festplatte .

hab mir die http://www.radonmaster.de/pvr-ripper/einw.html durchgelesen aber doch noch ein paar fragen

Sector 0x001-0x009 (9 stück)
Jedenfalls ist jeder FAT-Eintrag 4Bytes lang. Die ersten 2 Bytes verweisen
auf den nächsten Eintrag. Jeder Eintrag stellt einen Cluster dar. Die
zweiten 2Bytes sind unbekannt. Da zwei Bytes schon 6871947673600 Bytes, bzw.
6710886400 KBytes oder 6553600 MBytes bzw 6400 GBytes abdecken frage ich
mich wirklich wofür die andern beiden Bytes gut sind...

frage : Sector 0x001-0x009 (9 stück)
ist das der mbr ?

Sector 0x00A-0x06D (100 stück)
frage wieso 100 ? oder 100 als beispiel


Sector 0x06E-0x0FF (noch ein paar (145!!! stück)
leer... besser gesagt.. keine Ahnung. Vielleicht sind das die, die noch FILE
Beschreibungen beinhalten.

Sector 0x100-0x320ff
erster Videocluster

frage: warum hier erst viedeocluster nicht bei Sector 0x06E-0x0FF oder ist es möglich das in diesen sector ein film war jedoch gelöscht wurde ?

liegen viedeo und audio so weit auseinnander ?
woher weiss du das ?
audio und video wie werden die voneinnander identifiziert ?
Sector 0x32100-0x640ff
erster Audiocluster

Ich hoffe das ist eine brauchbare Einführung... <--jepp

EPG informationen auf der Platte rumliegen. Sehr seltsam...
meinst du das programm guide ?

ich hab noch google befragt nach der mpeg2 spezif.
aber leider so gut wie nichts gefunden (was taugt)
kannst du mir ne url geben wo das mpeg2 genau erklärt wird
wichtig wie headerinformation und viedeospur tonspur

Soviele Fragen auf einmal



Der MasterBootRecord ist prinzipiell bei FileSystemen der Sector 0. Das was du meinst ist die FAT (File Allocation Table).



Das ist eine willkürliche Festlegung seitens Hyundai, daß es 100 sind und zwar ist das genau die maximale Anzahl an möglichen Aufnahmen wenn ich mich richtig erinnere.



Es sollten maximal nur 100 Filebeschreibungen von 0x00A-0x06D anliegen und nicht mehr, da es ja auch nicht mehr Aufnahmen geben kann
Der Bereich 0x06E-0x0FF ist sicherlich als stille Reserve oder Temp Buffer freigehalten worden. Den kannst du fürs rippen getrost ignorieren.



Der Bereich bis 0xFF ist doch mit FAT und reservierten Sektoren bereits belegt also fängt erst bei 0x100 der erste Viedeocluster an.



Weil Hyundai Clustergrößen von 100MB pro Cluster festgelegt hat.



Aus dem gleichen Dokument wie du und ein bischen nachschauen auf der Platte. Nochmals: ich bin nicht der Coder vom Ripper, sondern hatte mich nur selbst ein wenig mit dem Thema beschäftigt, da ich für einen anderen Receiver einen Ripper am basteln bin



Schau dir doch mal die struct sFileDescription{} Description genauer an



Dieser Bereich ist immer für den 1. Audio Cluster auf der Platte reserviert und liegt genau 100MB "höher".
Denke immer an die Festlegung
Ein Sector=512 Bytes = 0x200 Bytes
Ein Cluster = 0x32000 Sectors = 100MBytes



Das EPG Daten (hauptsächlich RTL) auf der Platte abgespeichert werden ist ein Softwarebug des Receivers der nie behoben wurde
Dadurch kann es häufig vorkommen, daß kein EPG mehr auf den RTL Sendern und VOX geladen wird. Erst wenn man die Platte leer macht gehts wieder für eine Weile bis der Bug wieder zuschlägt und SI Daten auf der HD abspeichert.



Schau mal bei:
http://www.mpeg.org
http://www.wotsit.org
nach

danke für deine schnelle antwort

also liegen die dateien
video audio video audio video cluster u.s.w. vor ?
richtig ?
also wenn audio und video > 200 mb sind 400 mb "(belegt)" oder ?
jee clustergrösse 100 mb ist klar;

aber

Nun erkläre ich dir noch kurz was wir püber den FILE Sector wissen:

struct sFileDescription
{
__int8 iRecordNo;
char cStationName[0xE];
char cClipName[0x29];
__int16 iRecordYear;
__int8 iRecordMonth;
__int8 iRecordDay;
__int8 iRecordHour;
__int8 iRecordMinute;
__int8 iRecordSecond;
char cUnknown1;
__int8 iLengthHours;
__int8 iLengthMinutes;
__int8 iLengthSeconds;
char cUnknown2[0x11];
__int16 iVideoFatEntry;
__int16 iAudioFatEntry;
};


wie ist es wenn sagen wir mal 3 filme auf der festplatte sind
wie kommt man dann an die filebeschreibung ?
was ist genau mit filesector gemeint ?



schon mal vielen dank für deine geduld

und viel glück und ideen zu deinem project
in welcher sprache meisselst du ?

Jeder File Eintrag steht für eine Aufnahme.

Ist der File Eintrag vorhanden ist auch die Aufnahme da. Ist der Sektor leer mußt du zum nächsten Sektor gehen und schauen, ob ein Eintrag vorhanden ist.
So bekommst du erstmal eine Liste zusammen welche Aufnahmen überhaupt vorhanden sind.


In der sFileDescription Structure sind die letzten beiden Einträge sehr wichtig:
__int16 iVideoFatEntry ist ein Pointer auf den FAT Eintrag nur mit den Video Clustern der Aufnahme

__int16 iAudioFatEntry ist ein Pointer auf den FAT Eintrag nur mit den Audio Clustern der Aufnahme


In den zu diesen Pointern dazugehörigen FAT Einträgen hast du dann die Cluster Nummern stehen. In einer FAT stehen immer nur Audio oder Video Cluster, aber nie Audio und Video Cluster gemischt. Der iAudioFatEntry weist wie gesagt auf die FAT mit nur den Audio Cluster Einträgen hin und der andere Pointer macht das gleiche in grün für die Video Cluster.


Jedes Byte im FAT Eintrag steht für die Nummer eines Clusters. Da pro Sector 512 Bytes zu Verfügung stehen, die man nie benötigt, um die Cluster für eine Aufnahme abzuspeichern, werden nur die ersten Bytes mit Einträgen für verwendete Cluster genutzt und alle anderen auf 00 gesetzt.
Ein Beispiel:
Bei einer Aufnahme von 2GB wären das 20 Cluster à 100 MB. Man kann davon ausgehen, daß das ungefähr 17 Video Cluster sind und 3 Audio Cluster (halt das Verhältnis des Datenaufkommens der Videodaten zu der Audiodatenmenge).
In der FAT mit den Video Cluster würden jetzt 17 Bytes stehen und in der FAT für die Audio Cluster würden nur 3 Bytes stehen. Alle anderen Bytes sind wie gesagt auf 00 gesetzt.

Nun hast du die entsprechenden Cluster für die Video und die Audio Spur zusammen und mußt halt nur über die Clusternummer den Startoffset für den zu rippenden Cluster berechnen.
Du fängst bei 0x100 an und rechnest für jeden weiteren Cluster 0x32000 hinzu:
0x100 -> Cluster 1
0x32100 -> Cluster 2
0x64100 -> Cluster 3
usw.

Und damit hast du eigentlich alles um die Aufnahmen RAW rippen zu können


P.S.: Ich meissel hauptsächlich in VB6 und Delphi. Hin und wieder tue ich mir auch C++ an, aber da mache ich nur einfachere Sachen mit.
Dot.net lasse ich zur Zeit ganz außen vor. Das muß sich erst noch richtig durchsetzen bevor ich da tiefer einsteige
Außerdem hab ich keinen Bock meine VB Source auf VB.net zu portieren. Das ist mir zuviel Arbeit ohne daß ich Vorteile dadurch hätte.

na solangsam versteh ich das aber

also stehen die File Einträge in Sector 0x00A-0x06D demnach
ist die ganze sache art tabelarisch angeordnet ?
wie eben eine indexdatei mit den jeweiligen einträgen
wen ja dan ist das ja relativ einfach und sFileDescription vertikert mir dan welche art von datei und position oder?

aber dann müssen doch noch video und tonspur zusammengefügt werden den irgentwie soll ja ne svcd oder vcd
rauskommen
was meinst du läst sich das mit ein parr zeilen delphi ermöglichen
oder sollten das andere tools erlediegen(freeware) ?

Ist die Frage wirklich ernst gemeint ?!

Mit ein paar Zeilen Code ist das überhaupt nicht zu erledigen:
1.) Du mußt Code erstellen, für die Rip Funktionen.
2.) Die gerippten MPEG Daten müssen in SVCD kompatible MPEG Daten umgewandelt werden (Bitrate max. 2600kBit/s etc.)
3.) Du mußt eine ISO Datei erstellen (oder ein sonstiges Imageformat für die gängigen CD Brennprogramme), die SVCD kompatibel ist und die entsprechenden MPEG Daten erhält.

Soviel zum Thema "ein paar Zeilen Code"...

so

und wer so sagt ist noch lange nicht fertig

wie komme ich dann an

__int8 iRecordNo;
char cStationName[0xE];
char cClipName[0x29];
__int16 iRecordYear;
__int8 iRecordMonth;
__int8 iRecordDay;
__int8 iRecordHour;
__int8 iRecordMinute;
__int8 iRecordSecond;
char cUnknown1;
__int8 iLengthHours;
__int8 iLengthMinutes;
__int8 iLengthSeconds;
char cUnknown2[0x11];
__int16 iVideoFatEntry;
__int16 iAudioFatEntry;

mit readfile ?
wie kann ich dann die parameter auslesen ?
die api readfile scheint mir nicht die gesuchten informationen
an geben
in sector 10 hab ich den filmnamen gefunden
aber mehr nicht was zuminedesten im hexedit zu lesen ist ?

wäre es möglich nur die geripten audio oder video spuren zu lesen zwecks tests?

Schreib dir erst einmal mit Hilfe der API eine Function, die dir einen Sector ausliest und ein Array mit 512 Bytes zurückliefert. Dann kann man weitersehen.
Nur der API Aufruf alleine reicht nicht. Schau mal mit Google. Da gibt sicher genug Beispiele für.

Wenn du dann ein Array pro Sector auslesen kannst wirst du mehr sehen, als nur im ASCII Bereich des Hexeditors, da auch dir nicht sichtbaren ASCII Zeichen einen Wert im Array haben.

okay
aber sektoren kann ich jetzt schon auslesen egal welche
durch diskaccess <-- kommponente

sind die informationen bitweisse hinterlegt ?

von ascci in dezimal oder hex auch kein problem.

wichtig für mich wie die dateiinformationen hinterlegt sind

Vergiß die Diskaccess Komponenten. Die liefern meistens nur einen String zurück und damit kannst du nix anfangen.

Außerdem haben alle DiskAccess Komponenten, die mir bekannt sind haben ein riesiges Problem: sie erlauben keinen Zugriff auf Sektoren über der 2GB Grenze. Probier mal aus über 2 GB zu kommen, wahrscheinlich liefert dir die Komponente dann nur noch Müll.

Was du brauchst ist eine Function, die dir ein Array zurückliefert und dann kannst du auch die einzelnen Bytes des Arrays auswerten.
Welche Bytes du auswerten mußt steht doch klipp und klar in der FileDescription Structure.


Schau in die FileDescription, werte die Pointer auf die FAT aus und lese aus der FAT die entsprechenden Cluster Nummern raus. Dann kannst du auch die dazugehörigen Cluster rippen.
Was willst du mehr an Dateiinformationen?

Rippe mal jeweils einen kompletten Audio und einen Video Cluster runter und schau dir den Stream an.
Wie gesagt, es ist höchstwahrscheinlich MPEG TS mit 188 Byte Paketen. Alles was du dazu wissen mußt steht in der ISO, die ich oben angegeben hab.

okay hab deinen ratschlag beherzigt hier der code für die sectoren

procedure TForm1.LeseSector(StartSector : DWORD);
var
hDevice: THandle;
bytesread: DWord;
a : integer;
begin
hDevice := CreateFile('\\.\PHYSICALDRIVE1',
GENERIC_READ, FILE_SHARE_READ OR FILE_SHARE_WRITE,
nil, OPEN_EXISTING, 0, 0);
if (hDevice = INVALID_HANDLE_VALUE) then
begin
showmessage('Fehler der vorgang wird abgebrochen');
CloseHandle(hDevice);
exit;
end
else
begin
SetFilePointer(hDevice, (StartSector * 512), nil, FILE_BEGIN);
ReadFile (hDevice, buffer, 512, bytesread, nil);
CloseHandle(hDevice);
end;
// und nu was mit anfangen !!!!! mit buffer
end;

so hab dann nu die werte in byte im array funzt super
nach der filedescription wären
buffer[1] = RecordNummer
buffer[2-14] = stationname und so weiter
aber wie weiter die daten ligen im ascciformat vor 0-255

ich versteh den zusammenhang mit dem zeiger nicht ?
wie soll ich da nun rauslesen können z.B. iVideoFatEntry <-- 2 byte

zwar ein zeiger auf die fattabelle, von fattabelle zeiger auf cluster richtig?

ich glaub zwar das es eigentlich so einfach ist das es schon zu schwer ist .-(

die zeiger und so weiter sind ja da aber für mich unverständlich

ps das ist das erstemal das ich mir mit dem fatdateisystem auseinandergesetzt hab sonst
wusste ich nur was von clustern sectoren den namen eben halt
und das wars auch schon also vieleicht verständlich wenn ich mich ein bischen dämlich anstell