Qualitätsverlust nach dem schneiden gesplitteter Filme ?

[Martina]

Hallo.

Mein 5 Jahre alter Loewe Connect hat eine interne Festplatte, erlaubt aber das kopieren auf eine Externe nur, wenn sie mit FAT32 formatiert wurde. Dieses Format ist für Dateigrößen bis max 4 Gbyte ausgelegt. Aufnahmen, die darüber liegen, werden gesplittet. Für TS-Doctor natürlich kein Problem, doch eine leichte Ungewissheit bleibt, denn schließlich wurde der Film mehrfach getrennt. Ich weiß nicht genau, wie ich das formulieren soll..........ist das Endergebnis einer gesplitteten, geschnittenen und wieder zusammengesetzten Aufnahme mit einer ungeteilten, und auf eine NTFS Festplatte kopierten Filmdatei identisch, also sicht- und messbar?

LG, Martina

[Cypheros]

Die Trennung in TV-Geräten und Receivern ist normalerweise lückenlos und das Zusammenfügen mit dem TS-Doctor führt zu keinen sichtbaren oder hörenbaren Übergängen.

[Martina]

Danke, das reicht mir schon als Antwort.

[Apropo]

Das kann ich so nicht bestätigen.
Mein früherer Comaq Receiver hat die Aufzeichnungen auch gesplittet. Nach dem Zusammenfügen war an der Stelle immer ein ganz kurzer Ruckler.

[Djfe]

In der Theorie kann das gar nicht passieren, weil ein Transportstream sowieso schon in 188 byte Pakete aufgeteilt ist
wenn man an diesen Paketgrenzen teilt erhält man einzeln abspielbare Dateien (vereinfacht)

und diese kann man auch problemlos wieder zusammensetzen

wenn beim Abspielen auf dem Receiver kein Ruckeln (vor dem zusammenfügen) zu sehen war,
hat der TSD wohl einen Fehler gemacht, weil die Aufnahme deines Comaqs anders war

ansonsten wurde der Fehler auf Seiten Comaqs gemacht, weil falsch gesplittet wurde (und selbst der Comaq Probleme beim zusammenfügen hat)

wenn du noch ein Sample hättest wäre das sicherlich hilfreich

2 Dateien 10 Sekunden vor und nach dem Übergang sollten reichen, um es zu analysieren

[tsduser]

Hmm, nee, sooo einfach ist es (auch vereinfacht) dann doch wieder nicht, denke ich...

Richtig ist, dass man den Transport-Stream teilen darf, wo immer man moechte. Sonst muesste man beim Einschalten eines Receivers immer ein bischen "ueben", um ihn zum richtigen Zeitpunkt einzuschalten, wenn gerade ein Packet Start voruebertorkelt.
Es haengt dann von der Faehigkeit bzw. Toleranz des Abspielprogramms (bzw. Receiver koennen das sowieso) ab, dass es nicht mit dem Hinweis abbricht, dass das erste Byte der uebergebenden Datei nicht 0x47 ist, sondern sich erst einmal (ein bischen spaeter im Stream) synchronisiert, dann feststellt, was es so findet, daraus dann die relevanten Informationen ableitet, usw.usf.

Dei DATEI(en), in der Informationen des erzeugten Transport Streams auf einem angeschlossenen Datentraeger abgelegt werden, darf(duerfen) genauso an beliebigster Stelle (also auch innerhalb eines 188 [oder 192] Byte grossen Packets) gesplittet werden.

Auch hier haengt es von der "Intelligenz" des Abspielprogramms ab, ob die gesplitteten Teile dann wieder "nahtlos" aneinandergepackt werden.

So gibt es z.B. Receiver, die die aufgezeichneten Daten in 64MB grosse "Chunks" speichern. Wie man leicht auseinanderdividieren kann, passen hier keine solche Packets ohne Rest hinein. Also wird der "Rest" des "angebrochenen" Packets einfach in der naechsten Datei weitergeschrieben.
Bei einer solchen Aufzeichnung kann man folglich einfach die einzelnen gesplitteten Dateien binaer hintereinander in eine neue Datei kopieren, und alles ist gut.

Andere Receiver erzeugen z.B. gesplittete Dateien, die jede fuer sich mit den kompletten Header-Daten versorgt werden. Wenn die dann binaer aneinanderkopiert werden, gibt's leider u.U. Missverstaendnisse bei der Interpretation durch das Abspielprogramm, wenn diese zusaetzlichen Header-Daten nicht an dieser Position im Gesamtstream "erwartet" werden.

Und dann kommt noch hinzu, dass die zu interpretierenden Daten (Video- und Audio-Frames; die anderen "programmbegleitenden" Informationen sind da meist unkritisch) schon gleich gar nicht in nur 188 Bytes (bzw. noch weniger, wg. Header- und Identinfos) passen.
Wenn das interpretierende Programm jetzt ein Dateiende erkennt, und die noch nicht "komplett" eingelesenen Frame-Informationen an der Nahstelle verwirft, weil es nicht weiss, wie es diese mit den Informationen des naechsten Dateifragments "verheiraten" soll, dann kommt es zu den "Rucklern" usw.

Insofern ist es kein "Fehler" vom TSD, oder Comag oder irgendwelchen anderen Receivern, sondern der "Fehler" sitzt wie meist VOR dem Geraet, weil die erstellten Dateien falsch behandelt werden.

Auf jeden Fall waeren Samples sicher hilfreich. 10 Sekunden koennten aber vielleicht in heutigen HD-Zeiten mit .264-Kodierung zu wenig sein. Ebenso koennte zusaetzlich ein Verzeichnislisting vom Aufzeichnungsort hilfreich sein.

[Mam]

Hmm, nee, sooo einfach ist es (auch vereinfacht) dann doch wieder nicht, denke ich...

Doch, ist es 

Hier gehts nicht darum, dass ein Film irgendwo anfängt, sondern, dass ein Receiver aus Gründen des verwendeten Dateisystems die Aufnahme in mehrere verschiedene Teile auftrennen muß.

Und das passiert, wie Dfje schon richtig erwähnte, IMMER an sauberen Paketgrenzen oder meinetwegen auch "mittendrin", dann geht die nächste Datei aber genau mit dem nächsten Byte aus weiter (aus Gründen der einfachen Verarbeitung ist die Paketgrenze aber wesentlich wahrscheinlicher.

Alles andere würde zu Störungen in der Wiedergabe führen.

[Apropo]

Samples kann ich leider nicht mehr liefern, da ich inzwischen einen anderen Revceiver benutze, der alles am Stück aufnimmt.

Ich wollte das "Problem" auch jetzt nicht lösen, sondern nur drauf aufmerksam machen, dass es nicht zwangsläufig ohne weiteres komplett störungsfrei funktioniert.

Danke euch trotzdem für eure Erklärungen.

[tsduser]

@Mam:
Wo genau ist denn jetzt der Unterschied Deiner Aussage zu dem, was ich geschrieben habe? 

Aber trotzdem Danke fuer Deine Elektronenverwendung.

[Cypheros]

Mein früherer Comaq Receiver hat die Aufzeichnungen auch gesplittet. Nach dem Zusammenfügen war an der Stelle immer ein ganz kurzer Ruckler.

Ja, einige Receiver mit ALI-Chipsatz (Comag, Xoro, usw. erkennbar an der Datei info.dvr oder info3.dvr im Aufnahmeverzeichnis) fügt zusätzliche Pakete am Anfang der Zusatzdateien an, die zu Rucklern führen können. Allerdings erkennt der TS-Doctor solche ALI-Aufnahmen und entfernt die störenden Pakete beim automatischen Zusammenfügen.

[Djfe]

@tsduser ich ging auch nicht davon aus, dass man sie direkt binär aneinanderklatscht, sondern, dass es der TSD tut, der ein wenig intelligenter agiert

ich wollte nur sagen: wenn der Receiver es ohne Ruckler abspielen kann, gibt es auch eine Methode, diese korrekt aneinanderzuklatschen, ohne dass Ruckler auftreten

das bei apropro trotzdem Ruckler auftraten, kann ich mir nicht erklären
aber vielleicht sahen seine Header anders aus, oder damals beachtete der TSD diese noch nicht, keine Ahnung