GarbRec TAP

[stefan999]

Hi Homer,

erst einmal Danke für dein unermüdliches Testen !!!!

Ohne die entsprechende Datei habe ich darauf jetzt leider auch keine Antwort.

Da aber ausschließlich mit den PCR-Werten selbst gerechnet wird, muß eine entsprechend große Differenz vorliegen. Aber woher die stammt, kann ich auch nicht sagen, da ich mich mit dem Thema DVB / MPEG nicht so auskenne.

Eine Erklärung könnte sein, dass es dem Encode erlaubt ist, die "System-Clock" und damit aauch den PCR mit neuen Werten zu starten.

Aber dafür habe ich zuwenig Ahnung von dieser Materie. Vielleicht kann uns ja einer der Freaks hier helfen....

Gruß
Stefan

[Homer]

[quote=""stefan999""]Ohne die entsprechende Datei habe ich darauf jetzt leider auch keine Antwort.[/quote]Den Fehler durch das Schneiden des Nachlaufs konnte ich nach einem Schnitt am Anfang auch in der resultierenden 3 MB großen Datei beibehalten. Twin Peaks ist 1610 MB groß. Wenn es dir hilft, kannst du sie nächste Woche von meiner Platte herunter laden.

Viele Grüße
Homer

[stefan999]

[quote=""Homer""]Twin Peaks ist 1610 MB groß. Wenn es dir hilft, kannst du sie nächste Woche von meiner Platte herunter laden.[/quote]

Wenn ich den "Fehler" finden will, bleibt mir wohl nichts anderes übrig. Das wird ein Riesendownload !!!

Schönes WE noch.

Gruß
Stefan

[stefan999]

Hi Homer,

ich habe mal die gefundenen PCRs mit ausgeben lassen. Hier das Ergebnis für die Musik Zapp Kopie1 :

Code: Alles auswählen

Log started: 2007-10-07 16:10:16
Clustergröße = 3760

Datei: Musik Zapp Kopie1 2007-09-28.rec
 -->Startzeit: 2007-10-07 16:05 Ende: 2007-10-07 16:05 Dauer in Minuten: 0
 --> gefundener PCR = 296
 --> gefundener PCR = 315
 -->Sprung 1 um 16:05 für 19 Minuten
 -->1 Differenzen mit 19 min. Gesamtdifferenz
 -->19 min. Aufnahme lt. PCRs

Wie man sieht, sind in der Datei komische PCRs vorhanden.

Laß deinen Rechner heute Nacht an, dann kann ich mal den Download der großen Datei starten.

Gruß
Stefan

[Homer]

Wenn das Dateidatum nicht OK (vielleicht Null) ist, ist das für den Topf der 01.01.2003 00:00 Uhr.
GarbRec macht daraus:
-->Startzeit: 33307-08-232 00:00 Ende: 33307-08-232 00:57 Dauer in Minuten: 57

Viele Grüße
Homer

[Homer]

[quote=""Homer""]Diese Lücke ist mir von der Position (11:03) her unerklärlich:

Code: Alles auswählen

Datei: Twin Peaks ­ Maskenball ~ MysteryKrimiserie 2007-10-06.rec
-->Startzeit: 2007-10-06 01:00 Ende: 2007-10-06 01:57 Dauer in Minuten: 57
-->Sprung 1 um 11:03 für 376 Minuten
-->1 Differenzen mit 376 min. Gesamtdifferenz
-->434 min. Aufnahme lt. PCRs

Die Aufnahme ist noch nicht geschnitten. Die Angaben im Header stimmen.

Viele Grüße
Homer[/quote]
Nach dem Schnitt des Vorlaufs:

Code: Alles auswählen

Datei: Twin Peaks ­ Maskenball ~ MysteryKrimiserie 2007-10-06.rec
 -->Startzeit: 2007-10-06 01:00 Ende: 2007-10-06 01:49 Dauer in Minuten: 49
 -->Sprung 1 um 10:55 für 376 Minuten
 -->1 Differenzen mit 376 min. Gesamtdifferenz
 -->426 min. Aufnahme lt. PCRs

Nach dem Speichern des Nachlaufs:

Code: Alles auswählen

Datei: cut.rec
 -->Startzeit: 33307-08-232 00:00 Ende: 33307-08-232 00:05 Dauer in Minuten: 5
 -->Sprung 1 um 09:10 für 376 Minuten
 -->1 Differenzen mit 376 min. Gesamtdifferenz
 -->381 min. Aufnahme lt. PCRs
Datei: Twin Peaks ­ Maskenball ~ MysteryKrimiserie 2007-10-06.rec
 -->Startzeit: 2007-10-06 01:00 Ende: 2007-10-06 01:44 Dauer in Minuten: 44
 -->0 Differenzen mit 0 min. Gesamtdifferenz
 -->45 min. Aufnahme lt. PCRs

Der Nachlauf (136 MB) steht neben der ungeschnittenen Datei (1,6 GB) zum Download bereit.

Viele Grüße
Homer

[stefan999]

[quote=""Homer""]Wenn das Dateidatum nicht OK (vielleicht Null) ist, ist das für den Topf der 01.01.2003 00:00 Uhr.
GarbRec macht daraus:
-->Startzeit: 33307-08-232 00:00 Ende: 33307-08-232 00:57 Dauer in Minuten: 57

Viele Grüße
Homer[/quote]
GarbRec gibt die Datumswerte nur an die Firebird-Lib weiter.

Das Programm geht davon aus, dass der Toppi zumindest die elementaren Daten, wie Dateiname, Datumsangaben etc. richtig schreiben kann.

Der Download deiner Datei (Twin Peaks) läuft schon ein paar Stunden. Der läuft allerdings sehr schleppend (54 KB/s). Na ja, ich lass die Kiste heute nacht laufen.

Gruß und bis bald.
Stefan

[stefan999]

Zitat von Homer
Diese Lücke ist mir von der Position (11:03) her unerklärlich:
Code:
Datei: Twin Peaks * Maskenball ~ MysteryKrimiserie 2007-10-06.rec
-->Startzeit: 2007-10-06 01:00 Ende: 2007-10-06 01:57 Dauer in Minuten: 57
-->Sprung 1 um 11:03 für 376 Minuten
-->1 Differenzen mit 376 min. Gesamtdifferenz
-->434 min. Aufnahme lt. PCRsDie Aufnahme ist noch nicht geschnitten. Die Angaben im Header stimmen

Mir auch. Ich habe deine Datei mal auf meinen Toppi kopiert und bekomme keine Fehler:

Code: Alles auswählen

Log started: 2007-10-11 14:47:42
Clustergröße = 3760

Datei: Twin Peaks %AD Maskenball ~ MysteryKrimiserie 2007-10-06.rec
 -->Startzeit: 2007-10-11 11:59 Ende: 2007-10-11 12:56 Dauer in Minuten: 57
 -->0 Differenzen mit 0 min. Gesamtdifferenz
 -->58 min. Aufnahme lt. PCRs

Kann daher dein Problem nicht nachvollziehen. Macht deine Festplatte Dinge, die sie nicht machen sollte?

Gruß
Stefan

[Homer]

[quote=""stefan999""]Kann daher dein Problem nicht nachvollziehen. Macht deine Festplatte Dinge, die sie nicht machen sollte?[/quote]Nein. Ich habe den Ausschnitt mit dem Fehler (cut1) als cut2 wieder auf meinen Topf übertragen:

Code: Alles auswählen

GarbRec 0.01b gestartet: 2007-10-11 17:21:18
Clustergröße = 3760
Datei: cut2.rec
 -->Startzeit: 2003-01-01 00:00 Ende: 2003-01-01 00:05 Dauer in Minuten: 5
 -->0 Differenzen mit 0 min. Gesamtdifferenz
 -->5 min. Aufnahme lt. PCRs
Datei: cut1.rec
 -->Startzeit: 33307-08-232 00:00 Ende: 33307-08-232 00:05 Dauer in Minuten: 5
 -->Sprung 1 um 09:10 für 376 Minuten
 -->1 Differenzen mit 376 min. Gesamtdifferenz
 -->381 min. Aufnahme lt. PCRs

Der Fehler ist auch bei Twin Peaks mit korrektem Datum aufgetreten. Daran liegt es also nicht. Wenn ich davon ausgehe, dass beide Dateien identisch sind, der Fehler aber nur bei einer gemeldet wird, vermute ich, dass das Programm mehr Daten einliest als zur Datei gehören.

Viele Grüße
Homer

[stefan999]

[quote=""Homer""]Wenn ich davon ausgehe, dass beide Dateien identisch sind, der Fehler aber nur bei einer gemeldet wird, vermute ich, dass das Programm mehr Daten einliest als zur Datei gehören.
[/quote]

Verstehe nicht so ganz, wie das gehen soll. Aber zur Vorsicht starte noch mal die neue Version (Achtung: die gibt alle gefundenen PCRs aus). Hat auch einen neuen OSD.

Gruß
Stefan

[Homer]

Code: Alles auswählen

Datei: cut1.rec
REC-Header enthält ungültiges Datum 0 (=MJD)

Dein Programm bearbeitet diese Datei leider nicht mehr.

Viele Grüße
Homer

[stefan999]

[quote=""Homer""]

Code: Alles auswählen

Datei: cut1.rec
REC-Header enthält ungültiges Datum 0 (=MJD)

Dein Programm bearbeitet diese Datei leider nicht mehr.

Viele Grüße
Homer[/quote]


Laß mal bitte auf TwinPeaks laufen. !!!

[Homer]

Die hab ich nicht mehr auf dem Topf, nur noch auf dem PC. Wie die Erfahrung gezeigt hat, tritt damit der Fehler wahrscheinlich nicht mehr auf.

Viele Grüße
Homer

[stefan999]

Hi,

bitte nicht wundern: Ich habe den Titel des Threads geändert, da der Threadtitel überhaupt nicht mehr zu den Beiträgen passt.

Gruß
Stefan

[asrael]

[quote=""stefan999""]Hi,

bitte nicht wundern: Ich habe den Titel des Threads geändert, da der Threadtitel überhaupt nicht mehr zu den Beiträgen passt.

Gruß
Stefan[/quote]

Hi,

vielleicht könntest Du auch mal irgendwo kurz zusammenfassen, was das TAP eigentlich bewirken soll?

Mit freundlichen Grüßen

asrael

[stefan999]

[quote=""asrael""]Hi,

vielleicht könntest Du auch mal irgendwo kurz zusammenfassen, was das TAP eigentlich bewirken soll?

Mit freundlichen Grüßen

asrael[/quote]

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

[Homer]

Die aktuelle Version gibt also für jeden Cluster den ersten gefundenen PCR aus. Kann es sein, dass der letzte Cluster weniger als 30 Sektoren enthält, die noch zur Aufnahme gehören und dass in diesen vielleicht gar kein PCR mehr steht. Dann könnte ein dahinter liegender Sektor einen falschen PCR liefern.

Viele Grüße
Homer

[stefan999]

[quote=""Homer""]Die aktuelle Version gibt also für jeden Cluster den ersten gefundenen PCR aus. Kann es sein, dass der letzte Cluster weniger als 30 Sektoren enthält, die noch zur Aufnahme gehören und dass in diesen vielleicht gar kein PCR mehr steht.[/quote]
Ja, das ist sogar wahrscheinlich.

Dann könnte ein dahinter liegender Sektor einen falschen PCR liefern.

1. Das ist insofern unwahrscheinlich, da HDD_FindPCR immer genau im Abstand von 188 Bytes (=Paketgröße im TS-Stream) sucht. Jedes Paket hat zu Beginn eine Kennung (0x47) sowie diverse Flags, über die man erkennen kann, ob üherhaupt ein PCR in dem Paket vorhanden ist. Das sich jetzt rein zufällig direkt nach einer Aufnahme gültige TS-Pakete befinden ist mehr als unwahrscheinlich.
2. Für den unwahrscheinlichen Fall, das dem doch so sei, wird von GarbRec bei der Verarbeitung des letzten Clusters (nur der kann ja teilweise gefült sein) der nicht zu der Aufnahme gehörende Teil mit 0x00 gepadded. Damit gibts keine 0x47 mehr und damit auch keine PCR.

Hier das Stück Code:

Code: Alles auswählen

// -------------------------- CorrectBuffer----------------------------
//
void CorrectBuffer(TYPE_File* f,char* p)
{
	dword usedBytes = (clusterSize << 9) - f->unusedByte;

	p+= usedBytes;

	if (usedBytes < MINBUFFERSIZE)
		memset(p,0,(MINBUFFERSIZE-usedBytes));
}

Gruß
Stefan

[Homer]

[quote=""stefan999""]

1. Das ist insofern unwahrscheinlich, da HDD_FindPCR immer genau im Abstand von 188 Bytes (=Paketgröße im TS-Stream) sucht. Jedes Paket hat zu Beginn eine Kennung (0x47) sowie diverse Flags, über die man erkennen kann, ob üherhaupt ein PCR in dem Paket vorhanden ist. Das sich jetzt rein zufällig direkt nach einer Aufnahme gültige TS-Pakete befinden ist mehr als unwahrscheinlich.

[/quote]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.

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.

Viele Grüße
Homer

[asrael]

[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]

Aha, danke.

Das ist aber ein esoterischer Fehler. Hat den außer Homer noch jemand?

Mit freundlichen Grüßen

asrael