Star Trek Voyager NTSC bessere Qualität als die PAL Version?

    Zitat von TheGenesis


    Warum ist's immernoch kein 4:3???


    Die Auflösung ist bei deinem encode 720x576 was nun mal nicht 4:3 ist, mach doch mal bitte einen encode mit den 768x576.

    Zitat von TheGenesis


    Aber wenns "sch***e aufgenommen" wurde, was machts für einen Sinn, das so hinzunehmen?
    Ich seh das eher sportlich. Frei nach dem Motto: "Mal gucken, was so geht" :)

    Ja kann man dann als Sport bezeichnen :) ist halt ne menge arbeit.


    Jetzt hatte ich so eine art Deja vu als ich deine arbeitsschritte gelesen hatte. bis auf die NTSC geschichte kommt mir alles sehr bekannt vor.
    (ich habe immer ALLES von den Serien aufgehoben, alle Sprachen alle untertitel und Kapitel mit den richtigen kapitelnamen, stehen ja alle schön in dem dvd-menü)

    ich lag da auch immer so bei knapp 3 monaten....grüsslig wenn ich jetzt so drüber nach denke :)

    Was dein "schneiden angeht"
    Ich selbst mag mir bei Serien auch nicht dauernd das Intro anschauen.
    Daher habe ich dann vor vielen jahren zu mkv als kontainer gewechselt denn mit den "ordered chapters" muss man nichts scheiden und kann dennoch film-stellen weg lassen. ok - die folge ist dann etwas größer, aber wer heute noch wegen platz jammert der sollte einfach mal ne neue Festplatte kaufen.


    EDIT:
    Würdest du für uns alle die arbeit machen und ordentliche Kapitel dateien erstellen, wenn du schon dabei bist?

    Zitat von hubblec4

    Die Auflösung ist bei deinem encode 720x576 was nun mal nicht 4:3 ist, mach doch mal bitte einen encode mit den 768x576.

    Oh wohl ... is jetzt mit SAR 16:15 anamorph kodiert.
    Müsste ich das aus irgendeinem anderen Grund resizen,würde ich das glatt auf die enkodiert- korrekte Aspect-Ratio ziehen, aber es gibt keinen Anlaß, das auf 768 zu strecken und das vom Abspieler dann nochmal strecken zu lassen.
    Qualität und Details gewinn ich dabei nicht und der in dem neuen Clip eingebaute Hint bringt den Abspieler dazu, das in der korrkten Ratio darzustellen.
    Aufpusten kostet nur zusätliche Bitrate und zusätzlichen Schärfeverlust.

    Zitat von hubblec4

    <Schneiden vs. Chapters>


    Nee ... geht gegen meine Überzeugung und setzt auch wieder voraus, das der Player das auch berücksichtigt ... Außerdem bin ich "Programmierer alter Schule" und da wird kein Speicherplatz verschenkt :)
    Wenn ich das mit Chaptermarken versehe is das ähnlich viel Aufwand wie beim schneiden ... da drück ich dann halt noch zusätzlich "entfernen" und muss das dann halt noch einmal abspeichern.
    Im Zeitalter von SSDs kostet das auch nur ein bis zwei Züge an der Zigarrette :)

    Zitat von hubblec4

    Würdest du für uns alle die arbeit machen und ordentliche Kapitel dateien erstellen, wenn du schon dabei bist?


    Kapitel Dateien?

    Hab jetzt die erste Episode NTSC hier liegen ...

    Arrrgghhh ... sieht so aus, das wären die RC1 auf DVD5 gequetscht worden.
    Oder ich hab hier eine gerippte Version erwischt, obwohl sie wie eine "untouched" aussieht.

    Das ist zwar relativ (zur PAL) smoothy, aber da fehlt über ein drittel an Bitrate ... viele viele Kompressionsartefakte, welche die Details kaputtmachen.
    Die PAL DVDs kommen im DVD9-Format ... kann das mit den RC1 jemand bestätigen? Ich find nirgendwo 'ne "technical Details" dazu.

    Gruß
    Thom

    Zitat von TheGenesis

    Von den NTSCs, von den PALs oder von meinen geschnipselten? :)


    Naja am besten halt origignal von einer DVD, vorzugsweise die PAL da ich noch nie eine NTSC version in der hand hatte.


    Mir fehlt leider momentan jegliche zeit, sonst würde ich es selber machen :(

    Ich hatte mir ja vorgenommen zu weihnachten mit den TNG's Blurays anzufangen, na mal sehen.
    Auf jedenfall habe ich durch das thema wiedermal lust auf DS9 und Voyager bekommen, alles schon 5 jahre nicht mehr geschaut.

    So ... hat sich erledigt ... hab das Zeugs durch'n IVTC gejagt und halbwegs filtern können.

    Das Ergebnis:

    Schön smoothy ... wenn man die duplicates extrapolieren würde (z.B. unter zuhilfenahme von SVP o.ä.).
    So starke Kompressionsartefakte, das wenn man die wegbügelt, die Details in den Stills viel schlechter werden, als das beim PAL-Material nötig wäre.
    Genauso vermischen sich die Details mit den Artefakten bei schnellen Schwenks, weil beim encoden nicht genügend Bitrate zur Verfügung gestanden hat.

    Kurzum ... Höherer Aufwand und weniger Details (oder wahlweise extrem wahrnehmbare Artefakte) gegen ein wenig mehr smoothness bei schnellen Szenen.

    Und da die Folgen zu einem Großteil aus Dialogen und relativ langsamen Szenen bestehen, bleibe ich bei PAL.

    Echt schade, das die das Zeugs auf kleine DVDs gepresst haben ... Tribble-Strafe steht an :D

    Da die DVDs in allen PAL-Ländern (wie Deutschland, Großbritannien und Australien) als DVD9 veröffentlicht wurden, kann ich mir eigentlich nicht vorstellen, dass die Serie in den USA WIRKLICH auf DVD5 rausgekommen ist - erst recht nicht mit "Hard-Telecine" (sprich: mit real codierten 29,97fps, statt 23,976fps mit Pulldown-Flag). Eventuell hast du da wirklich Rips in die Finger bekommen :( ...


    Zitat von TheGenesis

    wenn man die duplicates extrapolieren würde (z.B. unter zuhilfenahme von SVP o.ä.).


    Ich bin verwirrt: du hast nach 'ner IVTC noch Dupes und willst SVP darauf hetzen :huh: ? Nach einer IVTC sollten doch eigentlich keine Duplicates mehr vorhanden sein (sofern du einen Fieldmatcher UND einen Decimate-Filter eingesetzt hast... und nicht nur ersteres). Abgesehen davon, ist doch SVP zur Framerateninterpolation gedacht und nicht um doppelte Frames zu finden oder zu entfernen - oder hab ich da was missverstanden :hm: !? Ich bin echt irritiert...

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

    Ja, der Fieldmatcher bringt das Dup-Frames und der Decimate entfernt das.
    Problematisch ist, das an der Stelle der Dups dann genau ein Frame fehlt um die flüssige Bewegung zu erhalten.
    Das könnte darauf hindeuten, das tatsächlich jemand das eigentlich progressive Originalmaterial runtergerippt hat.

    Oder die bei Paramount haben ein paar Stockschläge verdiehnt ;D

    Mhmm ... wenn ich mir die NTSCs jetzt auf Verdacht kaufe und dann feststelle, das die Schuldigen beim Publisher liegen, spring ich hier im Dreieck ... grübel ... find keine Info's über das DVD-Format der Releases.
    Vielleicht schreib ich nochmal in anderen Foren.

    Zitat von TheGenesis

    Ja, der Fieldmatcher bringt das Dup-Frames und der Decimate entfernt das.
    Problematisch ist, das an der Stelle der Dups dann genau ein Frame fehlt um die flüssige Bewegung zu erhalten.


    Das sollte(!) aber normalerweise(!!) nicht der Fall sein :eek: . Eine IVTC soll ja schließlich die ursprüngliche Framerate wieder herstellen, die vor dem Pulldown vorlag...


    Zitat von TheGenesis

    Oder die bei Paramount haben ein paar Stockschläge verdiehnt ;D


    Ich glaube ja wirklich, dass da der Hund begraben liegt :( . Kannst du mal ein Video-Sample direkt von der NTSC-DVD anbieten? Mich würde echt mal interessieren, was die da "verbrochen" haben...


    EDIT:
    Ich hab gerade auf einer *räusper* nicht ganz legalen Seite ein paar aufschlussreiche Informationen gefunden:

    • Die NTSC-DVDs liegen wohl alle(?) als DVD9 vor.
    • Die Serie wurde offenbar mit "gemischter" Framerate produziert. Sprich: die Realaufnahmen wurden mit 24fps (respektive 23,976fps) gedreht... die Effektaufnahmen wurden hingegen mit 30fps (respektive 29,97fps) produziert. Die Realaufnahmen wurden dann per 3:2-Pulldown auf die höhere Framerate gebracht und mit den Effekt-Szenen kombiniert. Wenn man also auf die Realaufnahmen eine IVTC anwendet, erhält man ein fließendes Ergebnis... eine IVTC sorgt hingegen bei Effekt-Szenen für Ruckeln, da Frames "verloren" gehen. Jemand hatte sich daher die Mühe gemacht, die Episoden als Matroska-Dateien mit variabler Framerate zu rippen. Ein gigantischer Aufwand - aber vermutlich die einzig sinnvolle Lösung, wenn einem ein 100%ig sauberer Bewegungsfluss im Ergebnis wichtig ist.

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

    Ich glaube am "einfachsten" wäre es, die duplicates nicht zu dezimieren und dann zu ergänzen, sondern diese gezielt mit 'nem Interpolierer zu ersetzen.
    Dann müsste man nur noch wissen, wie man doppelte Frames erkennt und dann dem Interpolierer sagt, das er gezielt dort ein Zwischenbild berechnen möge.

    Hier ist mal ein Stück von dem NTSC Schrott, den ich "kriegen" konnte.

    2 Mal editiert, zuletzt von TheGenesis (14. Oktober 2015 um 22:02)

    Zitat von LigH

    Abschnittsweise MFlow-Interpolation?


    So(?):

    http://shareplace.com/?95BB9DD45

    ... und dann auf 25fps beschleunigen? Ginge wohl ganz gut - aber um das als eine halbwegs zeiteffiziente Lösung umzusetzen, die fast alles vollautomatisch hinkriegt und nahezu keinen manuellen Eingriff benötigt, fehlt meinereiner leider das Wissen :( .


    Zitat von TheGenesis

    Ich glaube am "einfachsten" wäre es, die duplicates nicht zu dezimieren und dann zu ergänzen, sondern diese gezielt mit 'nem Interpolierer zu ersetzen.


    Ich weiß nicht, ob das so schön aussehen würde. Die Abschnitte, die mit 29,97 progressiven Frames je Sekunde laufen mit 'nem Interpolierer auf 23,976fps runter zu rechnen, wird immer weniger optische Fehler produzieren, als das Hochrechnen der Abschnitte mit 23,976 progressiven Frames je Sekunde per Interpolierung auf 29,97fps:

    http://shareplace.com/?FCFAD76B5

    Hektische Bewegungen, sowie schnelle Bild- und Helligkeitswechsel, werden Frameinterpolationsalgorithmen wie MVFlowFPS und SVP/InterFrame immer aus dem Tritt bringen und Fehler produzieren, da die Algorithmen verzweifel nach ähnlichen Bildinhalten suchen, sie aber aufgrund der zu großen Unterschiede nicht finden können (siehe z.B. Tuvoks Kopf am Ende der Beispielszene, der wegen dem leichten Flackern zu "wabern" anfängt).
    Die Beispielszene mag noch erträglich aussehen - aber warte mal, wie es wirkt, wenn jemand beim Rennen gefilmt wurde, oder hektisch einen Arm bewegt :hm: ...

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

    Yepp ... andererseits wirks bei schnellen Horizontalschwenks eh immer verwaschen, da dürfte das kaum auffallen.
    Beim PAL Material gibts nur noch verwischte Pixelsoße :rolleyes_:

    Aber ich würde diesem "speziellen" Material erstmal garnicht soviel Aufmerksamkeit gönnen. Vielleicht ist das untouched garnicht so wild. Jemand hat ja scheinbar hier "heruntergerippt" ... wenn das irgendein Schwachmat einfach ohne groß zu überlegen nochmal durch 'nen MPEG2-Encoder gejagt hat, kann der werweiß was verwurschtelt haben.

    Ich versuche erstmal die Erste Episode untouched zu bekommen, bevor ich mir Magenschmerzen mit so einem sch***ß hole.

    Btw. das PAL-Zeugs, was die damals auf Sky und Sat1 gesendet haben, war noch schlimmer :ja:

    Ich hab nochmal über das Zeugs da oben nachgedacht ... eigentlich bräuchte man einen "ungeregelten" decimate.
    Quasi nur die doppelten Frames rauslöschen und das fertige Video mit 24fps (oder auch 25fps) abspielen.
    Die gelöschten Frames beim rauslöschen mit loggen und das Audio in den Bereichen entsprechend um 24/29,97tel shrinken.
    Et voila ... smoothy ohne irgendwelche Ruckler und synchron mit dem Ton.

    Haha ... ich glaube das wäre vom Aufwand dann der overkill ... mhmmm ... das Audio shrinken könnte man automatisieren ... aber wie erkennt man in Avisynth gleiche Frames, löscht diese raus und schreibt die Frame-Nummer in eine Protokolldatei?

    Zitat von TheGenesis

    Yepp ... andererseits wirks bei schnellen Horizontalschwenks eh immer verwaschen, da dürfte das kaum auffallen.


    Schnelle Schwenks sind weniger das Problem - denn Matsch der noch matschiger wird stört nicht ;) . Das Problem sind eher: Szenenwechsel... und Objekte, die sich schnell bewegen bzw. sich selbst oder ihre Position verändern (z.B. der Arm von jemandem, der winkt).


    Zitat von TheGenesis

    Jemand hat ja scheinbar hier "heruntergerippt" ...


    Könnten es vielleicht auch US-TV-Mitschnitte sein!? Mich hat in deinem letzten Sample nämlich die CC (Closed Captions) Einblendung irritiert, die ich eigentlich nur von US-TV-Ausstrahlungen kenne. Es gibt zwar auch NTSC-DVDs mit Closed Captions Untertiteln - aber da gibt's üblicherweise die Einblendung nicht. Ich kann und will allerdings nicht ausschließen, dass auch auf der DVD die CC-Einblendung vorhanden ist (eventuell, weil sie im Master vorhanden war :hm: )...


    Zitat von TheGenesis

    wenn das irgendein Schwachmat einfach ohne groß zu überlegen nochmal durch 'nen MPEG2-Encoder gejagt hat, kann der werweiß was verwurschtelt haben.


    Also bis auf 'ne relativ niedrige Bitrate und deren Nebeneffekt auf die Bildqualität sieht das Sample ziemlich "unverwurschtelt" aus ;D .


    Zitat von TheGenesis

    Btw. das PAL-Zeugs, was die damals auf Sky und Sat1 gesendet haben, war noch schlimmer :ja:


    Ist eigentlich verständlich. Wenn die Quelle schon so ein Misch-Masch ist, wird bei der Wandlung zu PAL garantiert nichts besser :eek: .


    Zitat von TheGenesis

    Ich hab nochmal über das Zeugs da oben nachgedacht ... eigentlich bräuchte man einen "ungeregelten" decimate.
    Quasi nur die doppelten Frames rauslöschen und das fertige Video mit 24fps (oder auch 25fps) abspielen.


    Wie soll das gehen? Es gibt zwar AviSynth-Filter, die tatsächlich nur doppelte Frames entfernen können und den Rest unangetastet lassen (z.B. das "gute" alte MultiDecimate). Aber hier gibt's das Problem, dass AviSynth eine konstante Framerate verlangt. Da versucht wird, die Laufzeit beizubehalten, hätte der Output (nach der Entfernung der doppelten Frames mit MultiDecimate) somit eine konstante Framerate irgendwo zwischen 23,976fps und 29,97fps (je nach Gewichtung der Szenen würde die Framerate auch noch von Folge zu Folge unterschiedlich sein -> sprich: Episoden mit mehr 29,97fps Material hätten eine höhere Durchschnittsframerate als Episoden mit weniger 29,97fps Material). Und das hieße: die Abschnitte mit 29,97fps würden langsamer und die mit 23,976fps schneller ablaufen -> der Ton passt nur noch am Anfang und am Ende einer Folge... aber nicht mehr in der Mitte:

    http://shareplace.com/?841CDB395

    Die einzig optimale Lösung wäre da DeDup statt MultiDecimate. DeDup kann nämlich ebenfalls doppelte Frames entfernen - produziert aber zusätzlich eine Timecode-Datei, die man beim Muxen in Matroska zum Erzeugen einer variablen Framerate nutzen kann:

    http://shareplace.com/?120387E85

    Letzteres ist vermutlich auch der Weg, den der weiter oben von mir erwähnte Ripper gegangen ist. Allerdings ist das ein ganz schöner Zusatzaufwand, da sowohl MultiDecimate, als auch DeDup vor dem eigentlichen Encoding einen Analyse-Durchlauf benötigen und zudem etwas Finetuning für den Encoding-Durchlauf brauchen, damit sie z.B. keine statischen Szenen fälschlicherweise als massenhaft doppelte Frames erkennen. Vorteil: das Ergebnis entspricht am meisten dem Original - OHNE Blendings, OHNE dazu "erfundene" bzw. interpolierte Frames und OHNE Ruckeln. Nachteil: nicht jeder Hardwareplayer kommt damit klar und eine sinnvolle PAL-Wandlung ist damit auch nicht möglich.

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

    Zitat von Tom Keller

    ...Das Problem sind eher: Szenenwechsel... und Objekte, die sich schnell bewegen...

    Ja, interpolation ist hierbei keine gute Idee. Bei Captures von Videogames funtkioniert das übrigens überraschend gut.

    Zitat von Tom Keller

    Könnten es vielleicht auch US-TV-Mitschnitte sein!? Mich hat in deinem letzten Sample nämlich die CC (Closed Captions) Einblendung irritiert...

    Ne, das ist auch bei dem PAL-Release drin.

    Zitat von Tom Keller

    Ist eigentlich verständlich. Wenn die Quelle schon so ein Misch-Masch ist, wird bei der Wandlung zu PAL garantiert nichts besser :eek: .

    Noch viel schlimmer, so wie es aussieht, haben die das NTSC-Material genommen und einfach alle Fields, die zuviel sind, übereinandergeblendet :(

    Zitat von Tom Keller

    Wie soll das gehen? <variable Framerate> ... der Ton passt nur noch am Anfang und am Ende einer Folge...

    Deshalb ja den Ton entsprechend anpassen. Das stelle ich mir so vor:

    1. Video encoden:

    Telecide(guide=0)
    FrameDoppeltDannLöschenUndPositionInDateiSchreiben("Logdatei.txt")
    AssumeFPS(25)

    2. Audio anpassen:

    a) Berechnungsproggi schreibt Anfang und Ende der Bereiche zwischen den Drops als TimeCode raus
    ***=Effektszenen, die jetzt mehr als 25fps beinhalten, also "zu langsam laufen"

    b) das Audio bei den ermittelten Bereiche um 29,97/25tel stretchen

    Dann hat man keinen manuellen Aufwand, kein hybridmaterial und kein ruminterpoliertes Zeugs und man braucht auch keine zusätzlichen Durchläufe oder ein spezielles Muxverfahren.

    Wenn ich mir das PAL-Material angucke, glaube ich fasst, das die dort sowas in der art gemacht haben.

    Einmal editiert, zuletzt von TheGenesis (15. Oktober 2015 um 09:56)

    Zitat von TheGenesis

    Deshalb ja den Ton entsprechend anpassen.


    Dir ist aber schon klar: wenn eine Szene von 29,97fps auf 25fps verlangsamt wird, dann ist das eine Verlangsamung um fast 20%!!! Zum Vergleich: der Geschwindigkeitsunterschied zwischen 23,976fps und 25fps beträgt nur 4%. 20% Geschwindigkeitsunterschied werden bei Musik und Dialogen extrem grausam klingen. Mir ist auch kein Fall bekannt, wo das jemals gemacht wurde - das fällt nämlich schlicht und einfach zu sehr auf. Deswegen wird NTSC-Material, welches mit 29,97fps gedreht wurde (bzw. auch NTSC-Mischmaterial aus "pulldowned" 23,976fps und 29,97fps Material), üblicherweise OHNE Geschwindigkeitsänderung zu PAL/50i konvertiert.

    Who is General Failure and why is he reading my hard drive?

    He was trying to get in touch with Private Data but if it involves a Major Disaster I understand that the fault lies with General Protection.

    Furthermore, if you cannot reboot it may be because of a corrupt Colonel.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden