Demux und transcode von MPA nach wav (aus Programstream) async

  • Hi leuz,

    weiss jemand nen Grund, warum der Audio-ES aus dem Teil hier noch sync ist, nach dem umwandeln zu WAV aber nicht mehr?

    Egal womit ich demuxe ... nach dem umwandeln zu WAV driftet es mit dem video auseinander ... und zwar ziemlich linear ... bis zum ende der Spieldauer (01:55 Std) ist das WAV ca. 1 Sekunde schneller als der original ES.

    Sind im AC3/MPA nach dem demuxen noch sync/timing Infos enthalten?

    Und warum schafft es nur ffmpeg das korrekt zu extrahieren? ... gleicht der eventuelle differenzen (wg. dropped o.ä.) beim herauskonvertieren aus?

    Gruß
    Thom

  • Zitat

    Egal womit ich demuxe ... nach dem umwandeln zu WAV driftet es mit dem video auseinander


    Sind extrahieren und Umwandeln bei wirklich zwei Schritte oder machst Du es teilweise in einen und manchmal separat,.. -> mehr Infos was Du machst wären hier nötig

    Zitat

    Sind im AC3/MPA nach dem demuxen noch sync/timing Infos enthalten?


    Nein, wenn es echte RAW streams sind nicht.

    Zitat

    Und warum schafft es nur ffmpeg das korrekt zu extrahieren?


    Im Vergleich zu? Macht eventuell Dein alternatives Tool stereo wav daraus?

    Zitat

    ... gleicht der eventuelle differenzen (wg. dropped o.ä.) beim herauskonvertieren aus?


    ffmpeg ignoriert eventuell manche Sachen, aber ausgleichen wäre mir neu
    Wie sieht den Dein ffmpeg Aufruf aus mit dem Du die Daten extrahierst?

    Zu den MediaInfo Daten:
    Komische Kombination. Progressive 29.970fps, und ac3 mit einer Datenrate von 56kBit/s.
    Wie wurde der Stream erstellt?
    Außerdem wäre eine detailliertere MediaInfo Analyse sinnig, da diese auch eventuelle Delaywerte in den Headern anzeigen sollte.

    Cu Selur

  • Wie kommst du auf MPA? Ich sehe hier nur MPEG2 als Videospur und AC-3 (Dolby Digital) als Audiospur, aber keinerlei MPEG-Audio.

    56 kbps für ein 1.0-AC3 (nur Center) ist vielleicht ungewöhnlich (v.a. qualitativ ziemlich wenig), aber wahrscheinlich durchaus im Rahmen der technischen Spezifikationen.

    Eine langsame progressive Asynchronität bei NTSC kommt mir aus meiner Zeit im DVD-Studio bekannt vor. Ich erinnere mich, dass es Drop- und Non-drop-Timecodes gibt, vielleicht hat das damit zu tun. Erklären kann ich den Unterschied aber leider nicht wirklich.

  • Zitat

    Egal womit ich demuxe ... nach dem umwandeln zu WAV driftet es mit dem video auseinander ... und zwar ziemlich linear ... bis zum ende der Spieldauer (01:55 Std) ist das WAV ca. 1 Sekunde schneller als der original ES.


    tatsächlich,ein paar Tools könnens nicht mal richtig demuxen.Procoder,Wavelab,LameXP....
    Das File geöffnet in Edius,Audioanteil codiert zu Wav,anschliessend in die zusätzliche Audiospur gelegt......kein Versatz.

    Ansicht im Procoder
    http://frupic.frubar.net/fullsize/29127

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Demultiplext hätte ich die Tonspur wahrscheinlich mit DGIndex (DGMPGDec). Anscheinend wurde das MPEG-PS ja im DVD-Modus multiplext, um die AC3-Tonspur da reinzukriegen (die ist schließlich auch nur in den DVD-Spezifikationen zusätzlich als Private-Substream definiert), also sollte jedes Tool damit klarkommen, das auch sonst VOBs ohne Rücksicht auf IFOs demultiplexen kann.

  • Zitat

    also sollte jedes Tool damit klarkommen, das auch sonst VOBs ohne Rücksicht auf IFOs demultiplexen kann.


    ist leider nicht so.

    DGIndex kanns zwar Demuxen,aber das Audio wird als "bad" angezeigt.
    Framerate 29,970030
    http://frupic.frubar.net/fullsize/29128
    http://frupic.frubar.net/fullsize/29129

    Testhalber das File in Samplitude Pro X Suite reingelegt..........hier wird mir nur die Umwandlung in Wave gestattet für die ev.Weiterarbeit.
    Audition CS5.5 wills gar nicht.

    Nun klappts mit der Umwandlung in LameXP zu Wave.
    http://frupic.frubar.net/fullsize/29130
    Da zeigts sich wieder mal...kostenlose Hilftools haben immer noch ihre Daseinsberechtigung.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

    Einmal editiert, zuletzt von Goldwingfahrer (4. April 2013 um 14:06)

  • Da hast du aber mal wieder die Hälfte übersehen.

    Was da auf rotem Untergrund als "Bad" angezeigt wird, steht in der Spalte "Quality". Da geht es um die Bitrate von nur 56 kbps für einen Mono-Kanal. Aber nicht um mögliche Datenfehler: Technisch ist die Tonspur vermutlich völlig in Ordnung.

    Ich wette, ein BeSweet-basierter Konverter (z.B. BeLight, HeadAC3he) oder ein AviSynth-basierter Konverter (BeHappy, MeGUI) hätten die AC3-Tonspur auch decodiert. Sogar mit der azid.exe als CLI-Tool hätte es geklappt. Leider habe ich keine Kopie dieses Videos, kann es also nicht selber überprüfen.

  • Zitat

    Sind extrahieren und Umwandeln bei wirklich zwei Schritte oder machst Du es teilweise in einen und manchmal separat,.. -> mehr Infos was Du machst wären hier nötig

    Erst habe ich, wie gewohnt, DGIndexNV das demuxen überlassen. Der macht ein AC3 daraus.

    Dann habe ich mit MPEG2VCR demuxed, weil der meistens meldet, wenn etwas mit dem ES nicht stimmt ... der erzeugt ein MPA ... habe aber gerade nochmal nachgeschaut ... es wird ein AC3 erzeugt, aber *.MPA genannt.

    Ebenfalls getestet mit VLC, direkt nach AC3 ... beim ausgeben via mpa stotterts ... also ist's auf jedenfall ein AC3, denn VLC hat beim umwandeln schonmal so seine problemchen.

    Die AC3's sind noch sync ... umwandeln nach WAV (besweet) machts async.

    Dann habe ich's direkt via Graphedit in eine WAV Datei gerendered ... async.

    Zitat

    ffmpeg ignoriert eventuell manche Sachen, aber ausgleichen wäre mir neu
    Wie sieht den Dein ffmpeg Aufruf aus mit dem Du die Daten extrahierst?

    Wenn ich ehrlich bin, habe ich das MPG-File einfach aus frust auf den "Pazera Free Audio Extractor" gezogen ... der arbeitet mit ffmpeg ... kriegt alles extrahiert :)

    Zitat

    Komische Kombination. Progressive 29.970fps, und ac3 mit einer Datenrate von 56kBit/s.
    Wie wurde der Stream erstellt?
    Außerdem wäre eine detailliertere MediaInfo Analyse sinnig, da diese auch eventuelle Delaywerte in den Headern anzeigen sollte.

    Weiss nicht, wie der Stream erstellt wurde ... Quelle war ein NTSC-VHS ... vermute die haben direkt nach MPEG2v und AC3 gecaptured.

    Welche Delaywerte meinst du? ... initial delay ist 0ms (behauptet zumindest DGIndex).

    Was mich so stutzig macht, ist nichtmal die Tatsache, das es nach dem konvertieren zum WAV async wird, sondern die Tatsache, das das AC3 noch syncron ist.

  • Naja ... ist halt ein Rückpro ... dafür günstig in der Anschaffung ... grins ... schlimmer als mit meinem 11 Jahre alten Toshiba kanns nicht werden :D

    Hast du lust, als Versuchskaninchen für meine C64-Säuberung herzuhalten?

  • Zitat

    C64-Säuberung


    Bin bereit wenn ein einigermassen gutes VHS/Video200/Betamax Band vorliegt den Film neu zu digitalisieren.
    Die Quali die uns Beiden vorliegt...da ist alles vergebliche Liebesmüh.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Ja, würd ich auch machen wollen, aber das meinte ich garnicht ... ich habs schon "getan" ... Urlaub halt ;)

    Du brauchst garnicht viel zu tun ... einfach mal 6 Versionen kurz auf deinem TV angucken und sagen, welche der 2*3 Varianten psychovisuell (noch) am besten rüberkommt.

    Ist nicht mal das Video an sich, sondern die Methoden, die ich bewerten möchte ... auf meinem Analog-Rückpro von 1924 seh ich nämlich kaum Unterschiede und auf dem 27" Iiyama von Sohnemann sehen logischerweise alle bescheiden aus.

    Ich würde dir die DVDs auch mit der Post zuschicken, dann brauchen wir uns die Leitungen nicht heißlaufen zu lassen.

    Wenn du Interesse hast ... ich hab jetzt 2x3 Versionen davon kodiert:


    Format 1 (DVD konform, MPEG-Program-Stream):

    Video: PAL (letterboxed), MPEG2, CBR 2350 zu 4500 zu 8000
    Audio: Stereo, 16 Bit, MPEG1 Layer 2, 224 kB

    Variante a) Interlaced
    Variante b) Pullup via Blend, Pulldown via FDecimate
    Variante c) Pullup via Extrapolate, Pulldown via FDecimate


    Format 2 (PC, XBox, PS3, etc., MP4-Iso):

    Video: H264, CRF 18
    Audio: Stereo, 16 Bit, AAC, q100 (~75 kB)

    Variante a) NTSC
    Variante b) PAL, Pullup via Blend, Pulldown via FDecimate
    Variante c) PAL, Pullup via Extrapolate, Pulldown via FDecimate


    Das Audio hab ich "nur angemessen" gereinigt, um das retro-feeling zu erhalten.
    Beim Video hab ich Hue, Intensität und Kontrast korrigiert, Chroma gesmoothed, mit der Brechstange gereinigt und scharfgezeichnet.

    Alles in allem recht gut gelungen (im Vergleich zum Ausgangsmaterial).

    Was mich hauptsächlich interessiert ist, welche der Varianten aus Format 1 auf einem (neueren) Analog-TV wirken und welche der Varianten aus Format 2 am besten auf einem HD-TV aussehen.

    Die Varianten 2b und 2c hab ich übrigens noch nicht encoded ... soll ich die vielleicht (weil flexiblere Zielplattformen/Player) besser nicht Letterboxen?

    Mhmm ... damit kommt gleich die nächste Frage auf ... wenn ich von PAL oder NTSC auf eine HD-Auflösung hochrechnen möchte, welches Upscaling-Verhältnis ist dann optimal, damit der Player/TV das möglichst verlustfrei auf die Endauflösung hochskaliert?

    ... grübel ... bei NTSC 480i ist das auf 720p ein Faktor von 1,5 ... klingt gut.
    ... bei PAL 576i ist das auf 720p jedoch ein Faktor von 1,25 ... schon schlechter.
    ... von NTSC 480i auf 1080p sind das wieder 2,25 ...
    ... und PAL 576i auf 1080p dann 1,875 ...

    vielleicht wäre es besser, PAL auf 720p zu croppen und PAL auf 1080p zu Letterboxen ... NTSC auf 720p kann so bleiben und NTSC auf 1080p evtl. Letterboxen ... oder sind die Resizer in den Wiedergabegeräten/TVs besser als Bilinear? ... was meint ihr?

    Gruß
    Thom

    3 Mal editiert, zuletzt von TheGenesis (5. April 2013 um 02:01)

Jetzt mitmachen!

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