DVD Stream Extraction: AudioSynch-Probleme mit einem PGC

  • Hallo,
    ich wollte einen PGC recoden, aber den originalen AC3-track dabei behalten.
    Das Problem daran ist der PGC selbst, der leider Asynchronitäten verursacht.
    Jetzt, weiß ich nicht genau, welche tools mir eine "korrekte" AC3-Datei liefern, weil viele eine anders "gerichtete" AC3-Datei liefern.
    PGC:
    Besteht aus einigen Teil-Cells des vollen TitleSets. D.h. im Vergleich zum vollen TitleSet sind hier in der Mitte an zwei Stellen einige Cells rausgeschnitten. Dadurch gibt's PTS-Sprünge an den Schnittpunkten und die Extraktsionsprogramme können damit nicht richtig umgehen.
    Diesen Teil-PGC habe ich als neue DVD extrahiert zu CF01_FILM (u.a. weil ich kein tool kenne, dass avisynth-Dateien nur auf best. PGCs zulässt; DGIndex indiziert ja auch immer nur die kompletten VOBs)
    Info über den TitleSet: zB eac3to-log:

    Code
    E:\CF01_FILM\VIDEO_TS>C:\eac3to\eac3to.exe VTS_01_1.VOB+VTS_01_2.VOB+VTS_01_3.VOB+VTS_01_4.VOB 2:video.eac3toExtract.m2v 3:audio.eac3toExtract.ac3 -keepDialNormVOB, 1 video track, 1 audio track, 39:46:551: Joined VOB file2: MPEG2, 576i50 (4:3)3: AC3, 2.0 channels, 192kbps, 48kHz, dialnorm: -27dBv02 Extracting video track number 2...a03 Extracting audio track number 3...v02 Creating file "video.eac3toExtract.m2v"...a03 Creating file "audio.eac3toExtract.ac3"...a03 This track is not clean.v02 Video has a gap of 17687 frames at playtime 0:24:07.v02 Video has a gap of 17702 frames at playtime 0:46:09.a03 Audio has a gap of 49808ms at playtime 0:24:57.a03 Audio has a gap of 49912ms at playtime 0:47:48.a03 Starting 2nd pass...a03 Realizing (E-)AC3 gaps...a03 Creating file "audio.eac3toExtract.ac3"...Video track 2 contains 105012 frames.eac3to processing took 1 minute, 5 seconds.Done.


    - Hier kommt zB das gleiche m2v raus wie von DGIndex.

    AudioDemux:
    - DGIndex liefert aber einige korrupte(wahrsch. unvollst.) AC3-frames, die von eac3to und implizit von mkvtoolnix einfach weggeworfen werden.
    - eac3to (wie oben benutzt), fügt einen großen Leerraum ein, um die fehlende Zeit zu überbrücken, was natürlich zu einer riesigen Asynchronität führt.
    - ProjectX fügt auch Leerframes ein, die ja wie gesagt falsch sind.
    - ac3fix (zB auf DGIndex' Datei) liefert eine "andere" Synchronität:

    Jetzt ist's ja so, dass dieser Cell-beschnittene TitleSet als DVD wunderbar funktioniert, weil an den Cellgrenzen ja für's playback nachsynchronisiert wird (oder waren's die VOBID-Grenzen, oder gar an allen VOBUs?). Beim Demultiplex ist aber die passende AV-Synchronisierung weg. Und das "Nachfixen" mittels ProjectX, ac3dec, oder eac3to muss fast schieflaufen, weil die ja nur einen Elementary Stream ohne die Synch-Info verarbeiten.

    Wie bekomme ich einen korrekten AC3-Stream für meine 105012 frames recodetes Video? :)

    shh

  • Fang doch noch mal ordentlich bei der DVD an: Entweder der Ripper kann die Hauptfilm-PGC mit Hilfe der IFOs im IFO- (oder Movie-) Modus korrekt extrahieren (und dabei gleich demultiplexen), oder wenn das komplette VIDEO_TS-Verzeichnis schon auf der Platte ist, dann PGCDemux.

    Aber bei den heutigen logischen Kopierschutztechniken, die mit absichtlich fehlerhaften Kopien der IFOs arbeiten, würde ich ein Ausleseverfahren bevorzugen, welches das UDF-Dateisystem (gegenüber ISO-9660) bevorzugt.

    Mehr sag ich dazu nicht.

  • Hi LigH,
    das Problem ist eigentlich nicht die korrekte Extraktion der DVD. Ich habe die schon ohne Probleme auf die Platte bekommen.
    Der Teil-PGC ist eigentlich auch selbst mit PGCEdit erstellt: Es sind 3 Animefolgen, die zusammengehören, aber in der Mitte wollte ich den Abspann und Vorspann je 2x raus, damit's quasi ein durchgehender FILM wird.
    Dies ist im Original via Cell-Jump-Befehle am Ende der Cells realisiert (man kann im Menü die "Voll"version und die "FILM"version auswählen).
    Ich habe mir einen Extra-PGC der entsprechenden Cells gemacht, was auf das gleiche rausläuft. Diese Cell-Jump-Befehle werden ja u.a. auch von PGCDemux ignoriert, deshalb war zumindest das Bauen einen neuen PGC nötig.
    Aber PGCDemux hab ich tatsächlich vergessen, danke!
    Ich probier' mal, was das für'n Audio ausgibt. Wobei ich aber vermute, dass der auch nur hart an den Cells trennt wie schon DGIndex. Mal schaun, Versuch macht kluch.

    shh

  • Zitat

    Jetzt ist's ja so, dass dieser Cell-beschnittene TitleSet als DVD wunderbar funktioniert,


    Dieses Teilstück abspielen.......mit Messer oder mit dem No23 Rekorder das Audio aufnehmen und dann mit LameXP oder Wav to AC3 Enc. neu in AC3 erstellen.Dies aber nur wenn`s mit PGCDemux nicht klappen sollte.

    shh...und sofort wusste ich wo ich Dich einreihen darf.Waren schöne Zeiten.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Vorher:
    Der CF01_FILM war ja via DVDShrink als neue DVD geauthored/extrahiert.
    Dann den Film via DGIndex indiziert und dabei den AC3-stream extrahieren lassen. Das brachte, wie gesagt einige unvollst. AC3-frames im stream.

    Jetzt das PGCDemux Resultat:
    - Audio ist Bit-identisch. D.h. eac3to und auch andere tools finden später kaputte AC3-frames, wobei dann wieder die Frage ist, wie "richtig" das korrigierte AC3 ist.
    - Video ist hier etwas größer als das Resultat von der DVDShrink-DVD. Achtung: Ich hatte mit DVDShrink nichts geschrumpft, das ist aber auch egal, weil die Framezahl gleich ist. DVD-Shrink verwendet vermutlich die kürzere Picture Coding Extension und/oder entfernt user-data. Es kann auch sein, dass DVDShrink die zwei B-frames wegwirft, die keine Rückwärtsreferenz mehr haben. Egal.

    Also, gleiches Problem: Der Cell-Cut ist auch hier fehlerträchtig, weil nach dem Durchlauf von eac3to oder ac3fix andere AC3-Synchronisationen rauskommen.
    Beide Programme wissen ja auch nicht die ursprüngliche Synch von A+V.

    Man bräuchte ein Programm, das das VOB ordentlich verarbeiten kann, bei Schnittpunkten müssen dann nicht die Cellgrenzen beachtet werden, sondern der PTS. Dann muss so geschnitten werden (weil die AC3-frames ja quasi nie zu den V-frames passen), dass beim Audio mal früher, mal später abgeschnitten wird, damit man zumindest im Mittel synchron ist.
    vstrip, DGIndex, PGCDemux und Konsorten halten sich leider zu genau an die Cellgrenzen.
    Das Problem ist der Schlittpunkt: Am Ende einer Cell kann laut AV-synch schon Audio für die nächste Cell kommen, oder einige Audio-frames kommen erst nach dem NAV-PACK (=Cellgrenze). Je nach AV-synch (= Verschiebung der Audio und Video-Pakete zueinander) hat man am Ende einer Cell zuviel, oder zuwenig Audio-frames.
    Ich glaube mein Versuch mit dem Cell-Splitting, wie in der orig DVD bringt nichts.
    Ich bräuchte ein Programm, das "intelligent" an den Cells splittet. Sowas macht normalerweise ProjectX, aber irgendwie hab ich dafür die richtigen Einstellknöpfchen noch nicht gefunden. (gibt's andere prgs?)

    Goldwingfahrer> shh...und sofort wusste ich wo ich Dich einreihen darf.Waren schöne Zeiten.

    Yepp! Hab aber kaum mehr Zeit für sowas - außer jetzt (Urlaub). ;)

    Goldwingfahrer> Messer oder mit dem No23 Rekorder das Audio aufnehmen...

    Hmm, ich wollte eigentlich nicht das AC3 dekodieren und neu recodieren. Nur "einigermaßen" AC3-frame-genaue Schnitte, aber eben keine größer werdende Asynchronität. Ein passendes WAV zum Recodieren würde mir auch DGIndex ausgeben (Audio ist nur 2.0ch).

    _________________
    Für nur einen Film könnte ich mir die paar fehlenden/zuviel-frames an den Schnittpunkten schon selber berechnen (AC3-frames zu ms berechnen -> schaun, ob Lücke ok...). Ich hab aber noch 12 weitere Filme der Serie, da hätte ich gerne ne einfachere Lösung gehabt. :ja:

    Hier mal die aktuelle Problem-AC3 mit zwei korrupten AC3-frames (LeeAudBi v0.2b):

    Code
    File ........: E:\CF01PGC\AudioFile_80.ac3Size ........: 100813926 bytes----------------------------------------- First Frame InfoSampleRate ..................: 0 (48000 KHz)BitRate .....................: 10 (192 Kb/s)Version (bsid) ..............: 8 (Standard)Bit Stream mode (bsmod) .....: 0 (main audio service: complete main, CM)Audio coding mode (acmod) ...: 2 (2/0 - L, R)Dolby Surround Mode .........: 1 (Not Dolby Surround encoded)Low frequency effects channel: 0 (Not present)Dialogue normalization ......: - 27 dBRF atenuattion ..............:-0,28 dB  Frame: 1 Languaje ....................: 0 (Not present)Audio Production Info .......: 0 (Not present)CopyRight bit ...............: 1 Original bit ................: 1 Timecode1 ...................: 0 (Not present)Timecode2 ...................: 0 (Not present)Additional Bsi ..............: 0 (Not present)Block switch flags ..........: 0 Dither flags ................: 3 Dynamic Range Info ..........: 0 (Not present)------------------------------------------- Rest of Frames  Frame   SR BR PB BS BM AM LF DN DyRaCo Bytes Before Header--------- -- -- -- -- -- -- -- -- ------ -------------------*   45229  0 10  0  8  0  2  0 27           291 at 34735396*   86521  0 10  0  8  0  2  0 27           579 at 66448231--------------------------------------------- Revised InfoRF Ov. Pr. min/max : -12,9 /-0,28 dBTotal Frames ......: 131267 Duration ..........: 4200,544 seconds. ( 1 h. 10 m. 0,544 s.)------------------------------------------------- End Info


    ac3fix von der Datei ist:
    Was bedeutet "wrongness", und welche frames schreibt er da (anscheinend auch mal 2x)?


    Hier stellt sich eben die Frage: wurde an den Schnittpunkten zuviel weggeschnitten, oder wurde gar durch den Cell-Split generell an den Grenzen zuviel AC3 erhalten.... :rolleyes_:
    Das ist ja ein generelles Problem beim Demux: Die ursprüngliche synch-info von A+V zueinander geht verloren.

    shh

  • Zitat

    Hmm, ich wollte eigentlich nicht das AC3 dekodieren und neu recodieren. Nur "einigermaßen" AC3-frame-genaue Schnitte,


    war ja nur so ne Idee.
    Solange die einem nie ausgehen.....
    Mit Womble schon mal probiert ?? ev.gibts da eine 30 Tage Demo.
    Ev.noch das Asbach-Uralt Tool VOBedit.......
    ..oder in Edius direkt als "Originalstream" capturen....

    Single Cell..ein Screen von früher,hochgeladen von Bigotti5

    Pgcdemux-2.Loesung.png

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Hallo, Danke für die Tipps!
    Die tools habe ich (zT schon vorher) ausprobiert.
    Wie ich mir schon dachte, gibt's hierfür leider keine "intelligente" Lösung. Das Problem liegt einfach an den harten Cell-cuts und der festen AC3-frame-Größe. ProjectX und MpegSchnitt könnten sowas wohl einigermaßen ausgleichen, aber die ganzen frame-Schnittpunkte in 40 Teile einfügen ist nicht lustig und bringt auch Sekundärprobleme.
    Nachdem ich die Quellen etwas mehr analysiert habe: Es tauchen nicht nur an den CELLIDs, sondern auch an den VOBIDs Asynchronitäten auf. :(
    Ich kann mir also keinen eigenen PGC basteln wie ich es bisher gemacht habe. Zumindest nicht zum Recodieren, wenn ich einen "seamless" Teil-Film der Quellstücke haben möchte.

    Weil die Quelle eigentlich eh Mono ist, und ich das _codierte_ pseudo-Stereo sowieso überflüssig ist, hab ich mich jetzt doch zum Audio-recodieren entschlossen (und zwar nach LAME MP3 -a -V2). Die vollen WAVs ohne Lücken habe ich jetzt extrahiert, originales Video lasse ich mir per avisynth splitten.
    Gibt's für's WAV splitten irgendne ne schnelle Lösung? (Ich hoffe, ich muss dafür meinen alten WAV-Splitter nicht umprogrammieren)

    NACHTRAG: Ist leider wirklich nicht anders gegangen. Es ist mir nichts bekannt, das wirklich framegenau splittet. Auch keine professionellen tools. Ich habe daher meinen WAV-Splitter erweitert, dass er alle PGCs nach chapter(frame-point) splittet und die Stücke in ein WAV zum recodieren zusammenfügt.
    Wer sowas kurioses mal mit WAVs machen möchte, soll sich bei mir melden. :D

    shh

    3 Mal editiert, zuletzt von shh (16. September 2011 um 03:40)

Jetzt mitmachen!

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