GarbRec TAP

[stefan999]

[quote=""Elle4u""]Falls Du immer noch etwas suchst:

Für Filer suche ich immer noch Hilfe/Unterstützung da es zeitlich bei mir etwas eng aussieht

Die Sourcen liegen bei und man müsste sich dann eben nur absprechen...[/quote]

Hi,

ich helfe gerne. Da ich aber ja noch im Moment "TAP-Lehrling" bin, sind meine Kenntnisse logischerweise nicht so umfangreich, wie die der TAP-Gurus hier.

Wenn dich das nicht abschreckt, werde ich mich gerne damit beschäftigen.

Kannst mir ja mal in einer pers. Mail so in Stuichworten sagen, was noch so anliegt und was ich dabei tun könnte. Mehr als das ich heulend in Ecke laufe, kann nicht passieren.

Viele Grüße
Stefan

[FireBird]

[quote=""stefan999""]Die simplen Methoden (Header überprüfen, Differenz aus ersten und letzem PCR ermitteln etc.) helfen ja auch nicht wirklich weiter, wie du dort bestätigt hast.[/quote]
Du könntest einen Scanner à la RecCopy basteln, der den ersten PCR eines jeden Clusters auf „seltsame“ Sprünge prüft. Das dauert dann pro Aufnahme nur ein paar Minuten.

[stefan999]

[quote=""FireBird""]Du könntest einen Scanner à la RecCopy basteln, der den ersten PCR eines jeden Clusters auf „seltsame“ Sprünge prüft. Das dauert dann pro Aufnahme nur ein paar Minuten.[/quote]

Wenn man sich mit MPEG und diesem "Gedöns" auskennen würde wahrscheinlich ja, aber wie schon zuvor geschrieben, damit hapert es bei mir. (Noch ?!!!) Vielleicht siehts ja demächst damit besser aus. Reizen würde mich das schon. Möchte aber im Moment keine Hoffnung wecken, die ich vielleicht nicht erfüllen kann.

Aber: Mein Ehrgeiz ist geweckt.

Gruß
Stefan

[FireBird]

[quote=""stefan999""]Aber: Mein Ehrgeiz ist geweckt.[/quote]
Dann helfe ich noch ein bisschen nach. Der TS-Header ist 4 Bytes lang, beginnt genau bei einer Cluster-Grenze und kommt alle 188 Bytes. Ist ein bestimmtes Bit gesetzt, kommt nach dem Header der PCR. Das und die etwas komplizierte Dekodierung des PCRs kannst Du mit der FBLib-Funktion HDD_FindPCR vergessen. Energie! :

/Edit: Schlüsse, die in einem Thread gezogen wurden, der eineinhalb Jahre alt ist, kannst Du praktisch vergessen.

[stefan999]

Hallo Firebird,

mal ein paar Verstädnisfragen:

1. Ich gehe davon aus, dass die Clustergröße systemabhängig und nicht dateiabhängig ist. Ist das richtig?
2. Wenn ich mit 1. richtig liege, bedeutet dass doch, dass ich HDD_GetClusterSize nur einmal zu Beginn der Verarbeitung und nicht bei jedem Read aufrufen muss, oder.
3. Die Clustergröße wird von HDD_GetClusterSize doch in Sektoren je Cluster (z.B 4) zurückgegeben?
4. Wenn ich also Cluster für Custer lesen möchte, dann muss ich doch die logische Clusternummer nach jedem Zugriff hochzählen und auch immer genau soviel Sektoren lesen, wie der Cluster groß ist (zumindest, wenn ich alle Daten haben will).

Wenn ich das bis hierhin richtig verstanden haben sollte, dann verstehe ich diese Befehlszeile aus RecCopy nicht:

HDD_BigFile_Read(Buffer, CurrentCluster * HDD_GetClusterSize(), 4, f);

Hier soll m.E. der nächste Cluster gelesen. Dazu wird zwar clusterweise durch die Datei "gesprungen", aber mit fixer Sektorenanzahl gelesen. Wenn die Clustergröße aber nicht genau 4 ist, dann fehlen entweder Daten (falls Cluster > 4 Sekt.) oder es wird falsch gelesen, weil der nächste Cluster nicht zwangsweise sektorenmäßig auf den vorherigen folgt. Es würden also zufällige Daten gelesen werden (Falls Cluster < 4 Sektoren).

Falls aber die Clustergröße immer 4 ist, dann bräuchte man doch HDD_GetClusterSize nicht.

Ich blick da nicht mehr durch. Mache ich da einen Gedankenfehler oder RecCopy?

Gruß
Stefan

[Bonni]

Ich hätte auch noch eine Idee für ein TAP: Die Möglichkeit, die Header der rec-Dateien in Bezug auf (EXT_)EVENT_INFO etc. am Topf zu ändern. Ich selbst scheue (vor allem aus zeitlichen Gründen) den Aufwand vor allem wegen der Tastatur (die IMHO sowieso eine "Funktion" in firebirds lib sein sollte...).

Jaja, Alex, ich weiß, ich bin noch mit TFHead für andere Header als 5000 in Verzug .

[FireBird]

[quote=""stefan999""][*]Ich gehe davon aus, dass die Clustergröße systemabhängig und nicht dateiabhängig ist. Ist das richtig?[/quote]
Sie ist Festplattengrößenabhängig.

[*]Wenn ich mit 1. richtig liege, bedeutet dass doch, dass ich HDD_GetClusterSize nur einmal zu Beginn der Verarbeitung und nicht bei jedem Read aufrufen muss, oder.

Jein. : Sie erleichtert die Berechnung der absoluten Leseposition. Klar kannst Du mit einem Sektor-Zähler arbeiten, aber den musst Du auch um SectorsPerCluster inkrementieren. HDD_GetClusterSize holt sich die Info nur ein Mal von der Platte und arbeitet danach selbst mit einer lokalen Variable und ist deshalb schnell.

[*]Die Clustergröße wird von HDD_GetClusterSize doch in Sektoren je Cluster (z.B 4) zurückgegeben?

Ja, wobei die kleinste Größe 2068 Sektoren pro Cluster ist.

[*]Wenn ich also Cluster für Custer lesen möchte, dann muss ich doch die logische Clusternummer nach jedem Zugriff hochzählen und auch immer genau soviel Sektoren lesen, wie der Cluster groß ist (zumindest, wenn ich alle Daten haben will).

Wenn Du alle Daten haben willst. Die logische Sektornummer ist (Cluster-Nummer + 1) * SectorsPerCluster. Du brauchst also nicht unbedingt zählen.

HDD_BigFile_Read(Buffer, CurrentCluster * HDD_GetClusterSize(), 4, f);Wenn die Clustergröße aber nicht genau 4 ist, dann fehlen entweder Daten (falls Cluster > 4 Sekt.) oder es wird falsch gelesen, weil der nächste Cluster nicht zwangsweise sektorenmäßig auf den vorherigen folgt. Es würden also zufällige Daten gelesen werden (Falls Cluster < 4 Sektoren).

Nein. CurrentCluster * HDD_GetClusterSize gibt die absolute Startposition, ab der gelesen werden soll. Da RecCopy nur Stichproben macht, liest es die ersten 4 Sekoren eines Clusters, da dort auf jeden Fall ein Videopakerl vorkommt, das auf Verschlüsselung geprüft wird. Damit wird die Lesezeit stark verkürzt. Die nächste Startposition wird richtig berechnet.

[quote=""Bonni""] Jaja, Alex, …[/quote]
Ich hab’ nichts gesagt.

MfG. Alex

[stefan999]

[quote=""FireBird""]Sie ist Festplattengrößenabhängig.[/quote]

Dann haben wir uns missverstanden. Meine Frage zielte in die Richtung: Ist auf einem ganz bestimmten Topf die Clustergröße immer gleich oder kann auf diesem Topf jede Datei eine andere Clustergröße haben. Mit anderen Worten: Gibt es auf einem System mehrere verschiedene Clustergrößen?

HDD_GetClusterSize holt sich die Info nur ein Mal von der Platte und arbeitet danach selbst mit einer lokalen Variable und ist deshalb schnell.

Wenn ich einmal zu Beginn HDD_GetClusterSize aufrufe und den Wert selbst in einer lokalen Variable speicher, dann wärs noch schneller, oder?

Ja, wobei die kleinste Größe 2068 Sektoren pro Cluster ist.

WOW !! Satte Menge.

Wenn Du alle Daten haben willst. Die logische Sektornummer ist (Cluster-Nummer + 1) * SectorsPerCluster. Du brauchst also nicht unbedingt zählen.

OK ! Verstanden.

Nein. CurrentCluster * HDD_GetClusterSize gibt die absolute Startposition, ab der gelesen werden soll. Da RecCopy nur Stichproben macht, liest es die ersten 4 Sekoren eines Clusters, da dort auf jeden Fall ein Videopakerl vorkommt, das auf Verschlüsselung geprüft wird. Damit wird die Lesezeit stark verkürzt. Die nächste Startposition wird richtig berechnet.

Das wirft eine weitere Frage auf:
Das Wort "Stichprobe" bedeutet ja in diesem Fall, dass das Ergebnis von 4 gelesenen Sektoren für 2068 steht. Habe ich das richtig verstanden?


Erstmal vielen Dankl.

Gruß
Stefan

[Homer]

[quote=""FireBird""]Sie ist Festplattengrößenabhängig.[/quote]
Daraus schließe ich ein "Nein" als Antwort auf diese Frage:
[quote=""stefan999""]Dann haben wir uns missverstanden. Meine Frage zielte in die Richtung: Ist auf einem ganz bestimmten Topf die Clustergröße immer gleich oder kann auf diesem Topf jede Datei eine andere Clustergröße haben. Mit anderen Worten: Gibt es auf einem System mehrere verschiedene Clustergrößen?[/quote]

Viele Grüße
Homer

[FireBird]

[quote=""stefan999""]Gibt es auf einem System mehrere verschiedene Clustergrößen?[/quote]
Nein, sie ändert sich nur, wenn Du die Festplatte tauscht und die Neue eine andere Grösse hat.

Wenn ich einmal zu Beginn HDD_GetClusterSize aufrufe und den Wert selbst in einer lokalen Variable speicher, dann wärs noch schneller, oder?

Minimal. Dafür verbrätst Du 4 Bytes. :

Das Wort "Stichprobe" bedeutet ja in diesem Fall, dass das Ergebnis von 4 gelesenen Sektoren für 2068 steht. Habe ich das richtig verstanden?

Ich fürchte, das habe ich jetzt nicht verstanden. HDD_BigFile_Read liest X Sektoren ab der Position Y. Da ich weiss, dass die von mir gewünschte Information innerhalb der ersten 2kB (4 Sektoren) vorkommt, lese ich nicht 1 oder 2MB von der Platte, sondern eben nur 4 Sektoren. Klar wird die nächste 2kB-Stichprobe ein Cluster (2068 Sektoren) weiter hinten gezogen.

[stefan999]

[quote=""FireBird""]Ich fürchte, das habe ich jetzt nicht verstanden. HDD_BigFile_Read liest X Sektoren ab der Position Y. Da ich weiss, dass die von mir gewünschte Information innerhalb der ersten 2kB (4 Sektoren) vorkommt, lese ich nicht 1 oder 2MB von der Platte, sondern eben nur 4 Sektoren. Klar wird die nächste 2kB-Stichprobe ein Cluster (2068 Sektoren) weiter hinten gezogen.[/quote]


Ich hab ja gesagt, von MPEG etc habe ich keine Ahnung.

Ich hatte euch aber so verstanden, dass jedes Paket aus 188 Bytes mit einem 4 Byte Header besteht, also 4 Bytes Header und 184 Bytes weitere Daten. Jeder Header hat doch Informationen zur Verschlüsselung etc.

Und wenn (mind.) 2068 Sekt. * 512 Bytes rechne, kommen viele 188 Bytes-Pakete dabei raus, die alle jeweils eigene Info zur Verschlüsselung haben (also zumindest theoretisch unterschiedlich "geflagt" sein können).

Wenn ich jetzt aber nur 4 * 512 Bytes als Stichprobe nehme, dann kommen sehr viel weniger 188-Byte Päckchen raus.

Es kann doch sein, dass z.b die ersten 100 Sektoren verschlüsselt sind, der Rest im Cluster nicht, bzw. umgedreht. Nicht das das schlimm wäre, aber das war das, was ich meinte, also ich sagte "4 Sektoren für 2068".

Gruß
Stefan

[FireBird]

[quote=""stefan999""]Und wenn (mind.) 2068 Sekt. * 512 Bytes rechne, kommen viele 188 Bytes-Pakete dabei raus[/quote]
(mind.) 5632, um genau zu sein. : (hab keinen Spock-Smilie gefunden).

Es kann doch sein, dass z.b die ersten 100 Sektoren verschlüsselt sind, der Rest im Cluster nicht, bzw. umgedreht.

Richtig. Wenn der Stream ab dem Zeitpunkt verschlüsselt wäre, bekommt RecCopy es im nächsten Cluster mit. Sind nur ein paar Pakete verschlüsselt, rutschen sie durch die Stichprobe durch. Deshalb heißt sie ja Stichprobe. Den kompletten Stream zu scannen, würde viel zu lange dauern. Wenn ein Stream nur für ein paar Pakete den Verschlüsselungsstatus ändert, wäre er nicht reparierbar.

[stefan999]

Recht herzlichen Dank für deine Geduld.

Die Sources von RecCopy hätten vielleicht gereicht, um etwas ähnliches nachzumachen, aber ich möchte ja verstehen und nicht blind abkupfern.

Gruß
Stefan

[stefan999]

[quote=""FireBird""]Du könntest einen Scanner à la RecCopy basteln, der den ersten PCR eines jeden Clusters auf „seltsame“ Sprünge prüft. Das dauert dann pro Aufnahme nur ein paar Minuten.[/quote]

Hallo Firebird,

ich habe jetzt so ein TAP "gebastelt" und mal auf eine Aufnahme (LOST) losgelassen. Dabei kam folgendes Phänomen bei heraus:

Mit dem Scannen der ersten 4 Sekoren eines jeden Clusters, wie bei RecCopy, kam heraus, das für ca. 70% der Cluster kein PCR von der Funktion HDD_FindPCR gefunden wurde. Eine Steigerung auf ca. 10 Sektoren brachte etwas besseres Ergebnis. Aber erst ein Wert ab ca. 20 Sektoren bring ca. in 95% der Cluster mindestens 1 PCR zum Vorschein.

Ich weiß aber nicht. was ich damit anfangen soll: Der Wert, den HDD_FindPCR zurückgibt, liegt bei jedem Aufruf zwischen 577 und 585.

Ich weiß nicht, was ich mit den Ergebnissen anfangen kann:

Es kommt am Ende folgendes raus:
Total Cluster: 981
718 gefundene PCR bei 20 gelesenen Sekoren je Cluster
Addition aller 718 Werte, die von HDD_FindPCR zurückgegeben wurden: 432862.

Welche Ergenntnis habe ich jetzt?

Gruß
Stefan

[FireBird]

Hallo Stefan,

RecCopy braucht nur irgendein Videopaket um den Verschlüsselungsstatus zu testen. Videopakete mit PCR sind viel seltener und deshalb musst Du größere Samples nehmen. Der PCR ist nichts anderes als ein 33-Bit-Counter, der mit 90kHz getaktet wird, d.h., dass er nach ca. 26,5h überläuft und wieder bei 0 beginnt. Nachdem 33 Bit blöd sind, rechnet HDD_FindPCR den Zähler in einen Minutenwert um. Wenn also am Anfang 577 und zum Schluss 585 gemeldet wurden, ist Deine Aufnahme 8 Minuten lang.

MfG. Alex

[stefan999]

[quote=""FireBird""]Hallo Stefan,

RecCopy braucht nur irgendein Videopaket um den Verschlüsselungsstatus zu testen. Videopakete mit PCR sind viel seltener und deshalb musst Du größere Samples nehmen. Der PCR ist nichts anderes als ein 33-Bit-Counter, der mit 90kHz getaktet wird, d.h., dass er nach ca. 26,5h überläuft und wieder bei 0 beginnt. Nachdem 33 Bit blöd sind, rechnet HDD_FindPCR den Zähler in einen Minutenwert um. Wenn also am Anfang 577 und zum Schluss 585 gemeldet wurden, ist Deine Aufnahme 8 Minuten lang.

MfG. Alex[/quote]

Ok, verstanden.

Bei Homers Problem würde das bedeuten, dass bei seinen Aufnahmen, wo z.B. 20 Minuten Aufnahme fehlen, Sprünge in den PCRs dann in dem Beispiel von 20 Minuten sein müssten, habe ich das richtig verstanden?

Gruß
Stefan

@Homer: Wir kommen hoffentlich langsam der Lösung näher.

[FireBird]

[quote=""stefan999""]wo z.B. 20 Minuten Aufnahme fehlen, Sprünge in den PCRs dann in dem Beispiel von 20 Minuten sein müssten[/quote]
Genau.

[stefan999]

Dann kommt jetzt das Schlimmste und Langwierigste: Eine GUI drum herum bauen.

Debugmodus ist doch einfacher.

Gruß
Stefan

[stefan999]

[quote=""FireBird""]Hallo Stefan,

Der PCR ist nichts anderes als ein 33-Bit-Counter, der mit 90kHz getaktet wird, d.h., dass er nach ca. 26,5h überläuft und wieder bei 0 beginnt. Nachdem 33 Bit blöd sind, rechnet HDD_FindPCR den Zähler in einen Minutenwert um. MfG. Alex[/quote]

Eine Frage habe ich noch zu der Funktion HDD_FindPCR:

PCR = (pBuffer [i + 6] << 19) | (pBuffer [i + 7] << 11) | (pBuffer [i + 8] << 3) | (pBuffer [i + 9] >> 5);

Der Counter ist 33 Bytes groß. Das bedeutet, man benötigt mind. 5 Bytes, um die Information abzuspeichern (4 Bytes*8 Bit) + (1 Byte mit 1 Bit)

Die Funktion wertet aber nur 4 Bytes aus. Die Shifts (19+11+3) schieben zwar auf 33, aber 1 Bit fehlt. Ich denke mir das ist Absicht, da dass irgendwo im Milli- oder Nanosekundenbereich ist, aber ich liege doch richtig, dass es fehlt?

Gruß
Stefan999

[FireBird]

Also wenn Du schon aus meiner Funktion zitierst: die Antwort steht genau eine Zeile darüber.


/Edit: Zusatz: die 33 Bits stehen nicht hintereinander, sondern werden durch Prüfbits unterbrochen, brauchen also mehr Platz.