GarbRec TAP

[stefan999]

[quote=""Homer""]Wievele Bytes enthält ein Cluster? Dies wird wahrscheinlich eine durch 4 teilbare aber nicht durch 47 teilbare Zahl sein. Damit gibt es 188 / 4 = 47 verschiedene Offsets, bei denen das erste TS-Paket beginnen kann. Ein TS-Stream wird also in einem von 47 Fällen nach dem Ende mit dem richtigen Abstand weitergeführt.
[/quote]


Nein. Die Clustergröße ist immer so ausgelegt, dass die Pakete am Start eines Clusters beginnen. Geht auch nicht anders, denn sonst wäre gewollter ein Sprung in einer Aufnahme nicht möglich, da ja 0x47 auch rein zufällig irgendwo stehen kann. Um also an einen Paketanfang zu kommen (wenn die Pakete nicht am Cluster ausgerichtet wären) müsste man den Stream von Anfang an bis zu der Stelle lesen. Durch die Clusterausrichtung kann man in jeden beliebigen Cluster springen und hat auf jeden Fall ein Paketstart vor der Nase.

Kannst du die Version so ändern, dass bei einem ungültigen Datum nicht abgebrochen wird? Z. B. das Datum 0 als den 01.01.2003 weiterverarbeiten.

Kein Problem. Werde ich aber durch einen Paramter in der INI (siehe auch mein Problem im Thread FirebirdLib viewtopic.php?p=274643#p274643 ) parametrisierbar machen á la "StopOnWrongDate=J/N".

Gruß
Stefan

[stefan999]

[quote=""Homer""]Wievele Bytes enthält ein Cluster? Dies wird wahrscheinlich eine durch 4 teilbare aber nicht durch 47 teilbare Zahl sein. Damit gibt es 188 / 4 = 47 verschiedene Offsets, bei denen das erste TS-Paket beginnen kann. Ein TS-Stream wird also in einem von 47 Fällen nach dem Ende mit dem richtigen Abstand weitergeführt.
[/quote]

Sorry, hatte die allererste Frage übersehen.

Wie du aus dem Protokoll von GarbRec sehen kannst, ist bei deinem Toppi (übrigens auch bei meinem) die Clustergröße = 3760 Sektoren

3760 Sektoren * 512 Bytes (Bytes/Sektor) ==> 1925120 Bytes

1925120 Bytes / 188 Bytes/Paket = 10240 Pakete (glatt, ohne Rest).

Gruß
Stefan

[Twilight]

[quote=""stefan999""]Hi,

das TAP ist auf Wunsch von Homer entstanden (siehe erste Seiten im Thread). Kurz zusammengefasst, prüft das TAP alle Aufnahmen im Hauptverzeichnis daraufhin, ob sich innerhalb der Aufnahme eine (zeitliche) Lücke befindet.

Dabei wird aus Performancegründen nicht die komplette Datei durchgeackert, sondern (ähnlich wie bei RecCopy) von jedem Cluster ein Sample gezogen. Soll heißen. Von jedem Cluster werden die ersten 30 Sektoren gelesen und der erste PCR gesucht (mit Hilfe der FirebirdLib Funktion HDD_FindPCR). Da diese Funktion Minutenwerte zurückgibt, wird geprüft, ob die Differenz zwischen dem zuletzt gefundenen und dem aktuell gefundenen PCR größer als 1 Minute ist. Da ja alle 100ms ein PCR im TS-Stream kommen muss, wird bei einem PCR-Unterschied von mehr als 1 Minute eine Lücke unterstellt. Das war's eigentlich im groben.
Gruß
Stefan[/quote]

dies wäre nun schön in deinem ersten beitrag hinein zu editieren, gleich mit downloadlink, bzw. datei dort nochmal verlinken.

danke

twilight

[Homer]

[quote=""stefan999""]Nein. Die Clustergröße ist immer so ausgelegt, dass die Pakete am Start eines Clusters beginnen.[/quote]Danke. Dann liegen beim Überschreiben eines Clusters die neuen TS-Pakete immer genau über den alten.

Entweder gibt es beim letzten Cluster eine Ende-Markierung (0xFF, EOF), oder eine Aufnahme wird über eine Längenangabe (oder Entsprechendes) begrenzt. Fall hierbei ein Fehler auftritt, würde man genau im Raster die alten TS-Pakete finden.

Viele Grüße
Homer

[FireBird]

Ich würde den letzten Cluster ignorieren. Dort steht immer Müll und wenn es MPEG-Müll ist, dann ist er auch richtig ausgerichtet.

[stefan999]

[quote=""FireBird""]Dort steht immer Müll und wenn es MPEG-Müll ist, dann ist er auch richtig ausgerichtet.[/quote]

Deswegen hatte ich die Routine zum Auspadden des Mülls geschrieben (siehe #118). Wenn ich den Müll lösche, sollte ich den letzten Cluster doch ohne Probleme nutzen können.

Kannst dir ja mal die Routine ansehen.

Gruß
Stefan

[stefan999]

[quote=""Twilight""]dies wäre nun schön in deinem ersten beitrag hinein zu editieren, gleich mit downloadlink, bzw. datei dort nochmal verlinken.

danke

twilight[/quote]

Bin nach längerer Zwangspause nun endlich dazu gekommen, deiner Anregung zu folgen. Danke für den Tipp.

Gruß
Stefan