Beiträge von shh

Dank für die ausführliche Antwort.

Nur mal so als Zwischenstand:
DTS ist ja auch lustig. Alles mit eac3to und dem (empfohlenen) ArcSoft-decoder decodiert, der glaube ich auch DTS zertifiziert ist.

Surcode encoder (kann bis 5.1 DVD-DTS): WAV->DTS->WAV: hier wird kein priming hinzugefügt.
DTS-HD Master Audio Suite (Referenz): WAV->.DTSHD->WAV: 1024 Samples priming -> audio hat ab dann 0.02133s delay.
DTS-HD Master Audio Suite (Referenz): WAV->.CPT->WAV: 0 Samples priming, also so wie bei Surcode.
Dieses .CPT ist anscheinend ein "Komtatiblitätsformat" von DTS, was zumindest bei der Konvertierung keine Leersamples einfügt.
Bei allen .dtshd Formaten hat man übrigens zB 768000bps statt 754500bps und 1509000bps statt 1509.750bps, k.A. ob das schon jemandem aufgefallen ist.
Komischerweise kann man mit der DTS-HD Master Audio Suite aber auch ein normales DTS Digital Surround bauen, was zwar meiner Ansicht nach DVD-kompatibel sein sollte, aber eac3to und den ArcSoft-decoder dazu bringt, 1024 priming-samples einzufügen.

C:\AUDIO>C:\eac3to\eac3to.exe half.cpt -logdts
+ DTS-Core
  - frameSize            1006
  - DTS-ES               -
  - channelNo            2
  - lfe                  0
  - channelDescr         2.0
  - samplingRate         48000
  - bitDepth             24
  - bitrate              754500
  - samplesPerFrame      512
  - copyHistory          1
DTS, 2.0 channels, 0:01:00, 755kbps, 48kHz


C:\AUDIO>C:\eac3to\eac3to.exe half.dtshd -logdts
+ DTS-Core
  - frameSize            1024
  - DTS-ES               -
  - channelNo            2
  - lfe                  0
  - channelDescr         2.0
  - samplingRate         48000
  - bitDepth             24
  - bitrate              768000
  - samplesPerFrame      512
  - copyHistory          1
DTS, 2.0 channels, 0:01:00, 768kbps, 48kHz


C:\AUDIO>C:\eac3to\eac3to.exe full.cpt -logdts
+ DTS-Core
  - frameSize            2013
  - DTS-ES               -
  - channelNo            2
  - lfe                  0
  - channelDescr         2.0
  - samplingRate         48000
  - bitDepth             24
  - bitrate              1509750
  - samplesPerFrame      512
  - copyHistory          1
DTS, 2.0 channels, 0:01:00, 1510kbps, 48kHz




C:\AUDIO>C:\eac3to\eac3to.exe fullBR.dtshd -logdts
+ DTS-Core
  - frameSize            2012
  - DTS-ES               -
  - channelNo            2
  - lfe                  0
  - channelDescr         2.0
  - samplingRate         48000
  - bitDepth             24
  - bitrate              1509000
  - samplesPerFrame      512
  - copyHistory          1
DTS, 2.0 channels, 0:01:00, 1509kbps, 48kHz

Kann das sein, dass eac3to für die "Spezial"bitraten (754500 und 1509750) ein Handling hat, 1024 Samples am Start autom. abzuschneiden?

+20ms:
Ok, hab's gerade nochmal gechecked. Mkvmerge hat beim AAC tatsächlich am Anfang was weggeschnitten und musste den Rest dann mit +20ms verzögern.
Das dürfte so i.O. sein, weil der QuickTime-Encoder (den ich verwendet hatte) ja 2112-leer-Samples am Anfang einfügt. Sogar wenn man selber DELAY-Werte eingibt, wird das implizite priming vom Encoder nicht vergessen. Gut!
Nur beim Demuxen mit MKVExtractGUI zu AAC und Remuxen läuft irgendwas verkehrt: Beispieleingaben von je -2ms bringen bei .M4A am Ende +18ms, jedoch beim .AAC komischerweise +19ms. Hmm.

Priming:
Nun gibt's ja auch zertifizierte Player am PC und Standalones mit zertifizierten DTS AC3 und auch LPCM und MP2. Ich denke, man kann davon ausgehen, dass der PTS-delay bei DVDs so passt, dass audio+video am Player "so synchron werden, wie sie beabsichtigt waren." D.h. Producer/Sound-Decoder haben die impliziten delays miteinbezogen.
Jetzt könnte es sein, dass man sich vom Konvertieren eines LPCM-Tons einer DVD nach zB AC3 einen impliziten Delay zuzieht. Sei's wg priming oder decoder-lag. Auch wenn man den AudioSkew (= PTS-diff) beachtet.
Fügen denn DTS/AC3-ENcoder am Anfang Leersamples ein, oder verwenden die zum Priming echte Audiodaten, die dann später auch ausgegeben werden?
Beim Abspielen wird dann wahrscheinlich auf das Initialisieren aller substreams gewartet, bevor alles synchron wiedergegeben wird.
Falls keine Leersamples eingefügt werden, wäre das encoder-Priming von DTS/AC3 zu ignorieren und man kann wild von DTS->AC3->FLAC->LPCM->... konvertieren, ohne Synchronität zu verlieren.
- wenn denn die DTS/AC3-decoder keinen decoder lag haben.

Decoder-lag:
Verbleibendes Problem sind aber Formate wie MP3. Dies ist nicht für Containerformate zertifiziert und muss von den Playern (egal ob Standalone oder PC) nach PCM konvertiert werden, um etwa einen AV-Receiver zu füttern.
Für Synchronität wird aber der "Audio Skew"-Wert hergenommen, also die entsprechenden PTSs des Containers. Die Folge wäre asynchrone streams, wenn der MP3-decoder die Priming-LeerSamples (528: http://lame.sourceforge.net/tech-FAQ.txt) nicht wegschneidet. LAME tut das zwar "neuerdings" schon (http://mp3decoders.mp3-tech.org/decoders_lame.html#delays), aber tut's auch libav, oder andere (hardware)Player-decoder?

Problem ist vielleicht auch bei FLAC vorhanden denke ich, nur etwas anders. Hier könnte der FLAC-decoder einen Ausgabe-lag haben (wenn auch keine zusätzl. priming-samples encodet werden)

Gibt's eigentlich einen Decoder-Lag von DTS, AC3, FLAC, AAC? Wurde das schon irgendwo getestet?
Hmm, daneben könnte es auch sein, dass hardware-decoder (am AV-receiver) keinen lag haben, Software-decoder aber schon.

NACHTRAG: Moment mal, decoder lag, nicht richtig darüber nachgedacht.
Das würde zumindest am PC bedeuten, dass die decoder am Anfang Leersamples ausgeben. Dies ist aber glaube ich noch keinem aufgefallen, ich denke der Aufschrei wäre doch recht groß.
Zumindest sowas wie XBMC, mplayer, ffdshow oder andere müssten die substreams doch eigentlich synchron bekommen, wenn der encoder nicht irgendwo implizit Leersamples einfügt.
Zwischenstatus:
Video: Priming: bestimmt!, decoder-lag: nein, denn wird vom Decoder via PTS synchronisiert.
DTS: priming: echte audio-samples?, decoder-lag: nein, denn wird vom Decoder via PTS synchronisiert.
AC3: priming: echte audio-samples?, decoder-lag: nein, denn wird vom Decoder via PTS synchronisiert.
AAC: priming: ja (Leersamples) -> fix beim multiplexen, decoder-lag: evtl. bei kleinen settop-Boxen mit AC3/DTS-Bitstreaming an AV-receiver, jedoch software-decoding von AAC.
FLAC: priming: nein, decoder-lag: evtl. bei kleinen settop-Boxen mit AC3/DTS-Bitstreaming an AV-receiver, jedoch software-decoding von FLAC.
MP3: priming: ja -> fix beim multiplexen? bei lame nicht???, decoder-lag: evtl. bei kleinen settop-Boxen mit AC3/DTS-Bitstreaming an AV-receiver, jedoch software-decoder von MP3.
Gerade MP3 wirft hier in jeder Hinsicht Fragen auf: Selbst, wenn normales Audio von lame bzgl encoder-priming/decoder-lag gefixt wird, ist das dann auch so, wenn MP3 in Containern wie MKV verwendet wird, oder werden da die leeren priming-Samples einfach abgespielt, sodass der Audiostream hinterherhinkt...?

NACHTRAG2: Gerade darüber gestolpert: http://forum.doom9.org/showthread.php?p=1563801#post1563801
Anscheinend fügen AC3-encoder doch auch Leersamples ein, zwar "unmerkbare" 5.33ms aber sie tun es.
DTS wahrscheinlich auch. Hmm, wieder zurück an den Start.

Grüße...

p.s. auf MP3 reite ich so rum, weil ich das gerne auch in MKVs hernehme. Bei 2ch besser als AC3 und echte VBR nach erforderlicher Quali: zB -V2

Hallo,
ich hab jetzt schon viel dazu gelesen, irgendwie wird's aber nicht klar. Ich fang jetzt mal so an:

Warum braucht AAC-LE in MKVs ein delay (mkvmerge setzt automatisch 20ms), AC3, DTS (mkvmerge setzt 0ms) aber zB nicht?
- obwohl AC3/DTS auch MDCT-Algorithmen verwendet (wie fast alle) und somit _auch_ ein sog. priming des decoders braucht.

Insb. schneidet eac3to ein vorhandenes delay eines Audiostreams weg (=PTS Differenz zwischen Video+Audio), aber beim neuen Multiplexen in mkvmerge als:
DTS: wird kein delay hinzugefügt, eine DTS-priming-Zeit wird also fehlerhafterweise(?) ignoriert.
AC3: wird kein delay hinzugefügt, eine AC3-priming-Zeit wird also fehlerhafterweise(?) ignoriert.
MP3: wird kein delay hinzugefügt, eine MP3-priming-Zeit wird also fehlerhafterweise(?) ignoriert.
AAC: wird aber ein delay hinzugefügt.

Diese En/DEcoder-Verzögerungen sind unterschiedlich und leider oft im Bereich, dass man es kaum merkt. Manchmal ist's aber doch störend - bei seamless-play ist eine exakte Synch sowieso erforderlich.
Am TV kommen noch zusätzliche Video-Verzögerungen dazu, weil da irgendwelche Aufbereiter arbeiten und dann murkst man selber noch am HDMI-delay rum, aber *immer* passt's nie.

Jetzt gibt's einige Verwirrungen meinerseits, wg ENcoder und DEcoder-delay:
1. welcher ENcoder hat welches delay? Insb. wieviel leer-frames/ms werden eingefügt, die dann auch beim decoding wieder verschluckt werden?
2. Welcher DEcoder hat welches delay? Insb. tritt dies nur am PC auf oder auch bei hardware-decoder (AV-receiver)?
3. Kann man bei Kontainerformaten generell eine Synchronität erwarten? Immerhin hat man video und audio, aber warum bekommt AAC +20ms, AC3 aber nicht?

Etwas zum Nachlesen zum MP3-delay:
http://mp3decoders.mp3-tech.org/decoders_lame.html
http://lame.sourceforge.net/tech-FAQ.txt
aber naja, diejenigen wissen schon, wo die Quellen sind.

Hat da jemand Durchblick? Wie (wo was warum) man das synchron bekommt?
Grüße...

Zitat von -TiLT-

Ich war der Meinung, dass sich CF käuflich erwerben lässt.
Vielleicht ist es dann weniger Aufwand, die französische Version wieder auf die deutsche Fassung zurückzuschneiden.

Ja, Quelle sind die Kauf-DVDs, wie gesagt sind die bei mir schon ewig im Regal. Einerseits hab ich die franz. Fassung nicht, andererseits dürfte es nur für _eine_ Folge (von 40) lustig werden, die Frameschnittpunkte rauszufinden. (Ich hab ja schon ewig rumgepfriemelt, um mir synchrone WAVs für meine Film-Fassungen zu schneiden. Siehe anderer thread).

Zitat von Propaganda

Aber,was einen wirklich am meißten stört,ist diese "eventuelle" Umrechnung von NTSC auf PAL.[...]

Das ist hier definitiv nicht vorhanden! Im Allg. ist der Film: ippippippipp, d.h. auf ein interlaced-frame folgen 2 progressive frames.
Manchmal hat man aber auch ipipip. Aber keine ppiip, wie es normalerweise bei einem 3:2-pulldown vorkommen würde.
Man hat auch keine field-Blends, sondern scharfe i-Kämme, wenn man mit dem YV12 ordentlich umgeht.
Wie gesagt da sind oft pans dabei, die vielleicht 10 sek dauern und frame für frame absolut ruckelfrei sind. zB Pan (vom Teil1, ~min5): http://www.multiupload.com/92ADIO4Z5W
Ich hab da schon andere Sachen drauf probiert (srestore, field-shifts in avisynth, und auch testweise field-swaps via ReStream). Das alles hat's nur schlimmer gemacht. Ich glaube, das ist wirklich ne echte 25fps-Quelle. Es wurde ja alles komplett neu vertont, da haben die einfach die originalen 24fps genommen und 25fps in den header geschrieben.

Zitat von Propaganda

Welche Folge ist das denn?

Öhm, bei meinem ersten Schnipsel bin ich mir nicht mehr sicher, ich hab hier auf der Platte auch ne ganz andere Ordnung: Alle ganzen 13 Filme in einem Rutsch. Zum Teil massive Unschärfe fängt aber mit den Sieben Steinen an (DVD3), die aber noch nicht nachbearbeitet wurde. Das krasse Filtern haben die erst ab DVD4 gemacht. D.h. produktionstechnisch haben die eigentlich erst die ersten 3 DVDs gemacht und dann die restlichen 4 (nicht wie die Veröffentlichung: zuerst 3, dann 4). Das sieht man auch am völlig anderen Authoring der DVDs.
Der Schnipsel dürfte also vom ersten Teil der DVD4 sein.

Unscharf sind ja zwar so ziemlich alle Folgen, aber das mit dem TemporalSmoother finde ich schon krass. Auch wenn's damals auch nichts anderes groß "berechenbares" gab. In den späteren Folgen haben die die Stärke wieder zurückgedreht, sodass die letzten Folgen "einigermaßen" bzgl Rauschen und Kantenschärfe werden. Viele jetzige Anime-Säuberungsfilter machen leider die - damals genialen :cool: - Effekte kaputt.

Zitat von Propaganda

...Institut gelesen,die sowas mit viel....mit sehr sehr viel Rechenzeit....rausgerechnet haben

Wie lange ist das her? Vor 1, 2 Jahren hätte ich mich ja nicht mal getraut, irgendwelche motion-compensated deinterlacer, oder geschweige denn x264 herzunehmen. Waren das tatsächlich TemporalSmoother-Effekte, also temporale Glättung über mehrere frames hinweg?

Längere Schnipsel hochzuladen ist ein bisschen ein Problem. Darf man sowas eigentlich runterladen, wenn's das nicht mehr zu kaufen gibt?

Ich fasse nochmal zusammen:
Für die ersten 3 DVDs passen meine QTGMC- und LimitedSharpenFaster-Zeilen recht gut, bleibt noch:

Problem1: Temporale Schatten ab DVD4. Keine Ahnung, wie ich die weg bekomme.

Problem2: Massive Flecken, Haare, Dreck und Kleckser über alle Folgen hinweg.
...zT nur ein frame. d.h. wenn man alle -2 bis +2 frames beobachtet, und der Fleck nur in genau einem frame drin ist, war's wirklich ein Fleck und kann entfernt werden? Wie macht man sowas in avisynth?
Oder geht sowas nicht? Wenn die Leute sprechen, bewegt sich der Mund ja auch nur in zT von frame zu frame. Oft sind aber Kopien der Mundposition in benachbarten frames enthalten. Hmm.

Problem3: Dot Crawls ...nur auf einigen Folgen, hab ich noch nicht näher eingegrenzt.

Problem4: Rainbows ...das sieht dann an feinen Kanten, die unregelmäßig gelb/braun/usw schimmern.

Problem5: evtl. Schwarzpunkt der Linien. Finde ich zwar eher unwichtig, in einigen Folgen ist das Schwarz aber doch recht braun.

Problem6: evtl. Bildstabilisierung. Manchmal schauts echt sow, wie von Hand abgefilmt, so wackelt die Kamera. Allerdings macht da eine generelle Stabilisierung wohl auch etliche gewollte Schüttel-Effekte kaputt.
_____
(Problem: Interlacing
Gelöst mit QTGMC
Problem: MPEG-Artefakte
Gelöst mit QTGMC (fft)
Problem: Unschärfe, Rauschen
Grob gelöst mit LimitedSharpenFaster und x264. Stärkere (andere Filter) radieren oft zuviel weg.)

Hi, herzl. Dank für's feedback!

Selur> AVS Script schon angeschaut?
Ja. Hat mich aber leider noch nicht viel weiter gebracht. Ich muss die einzelnen Optionen nochmal extra tunen und schaun, was passiert.
Insb. hab ich die Rainbow- und Dot Crawl Artefakte noch nicht bachtet, die in späteren Folgen auftauchen.

LigH> ... Restore24
Das ist scheinbar tatsächlich ein echter 25p Anime (aus meiner Laiensicht). Da sind Scrolls dabei, die über gut 20sek absolut sauber und ohne Ruckeln laufen (kann ich gerne raussuchen, falls gewünscht). Wahrscheinlich haben die einen speedup auf PAL gemacht - es wurde ja alles neu vertont: Trailer, Synchonisation usw. Da ist der speedup egal.
D.h. restore nach 24p hat nach meinen Versuchen bisher nichts gebracht. Es ist aber trotzdem Interlacing drin, zum Teil Ekliges: fields nur 1.5 Pixel verschoben - auch in den statischen Szenen, deshalb hab ich's mit dem QTGMC mit allen möglichen Optionen probiert.

Momentanes "nonplusultra":
QTGMC(EdiThreads=4, FPSDivisor=2, Preset="Slower", TR0=2, TR1=2, TR2=3, Sharpness=0.3, NoiseProcess=0, NoiseRestore=0,GrainRestore=0, DenoiseMC=true, NoiseTR=2, Sigma=2.5)
crop(16,2,-16,-2)
LimitedSharpenFaster(strength=120,edgemode=1,ss_x=2.0,ss_y=2.0,dest_x=688,dest_y=560)

Wichtig: Ausprobieren mit dem aktuellen x264 mit -n 150. Die Standardeinstellung von x264 glättet recht stark, so dass ein Vergleich von x264-inputs nur recht wenig bringt. x264 glättet (motion-compensated!) recht stark, was ich mal genutzt und einfach von QTMGMC "abgezogen" habe:

\x264.x86.exe cf14.test.avs -o FERTIGNEU.mkv --index cf14n.ffindex --sar 12:11 --fps 25 -I250 --colorprim bt709 --transfer bt709 --colormatrix bt709 --vbv-bufsize 17500 --vbv-maxrate 17500 --preset veryslow --tune animation -f1:0 --nr 150 -r11 -b7 --crf 18 --level 3.1

Auch mit den Std-Filtern hab ich rumgespielt: Optimum: -f1:0, alles andere ist einfach zu scharf (=MPEG-Artefakte) oder zu unscharf.
Ich denke, dass ich so Kruschpeln nicht zuviel rausgebracht habe, ohne allzuviel zu glätten. (leider habt Ihr nicht den Rest der ganzen Folgen).

Didée> Oh, Captain Future! Der Held meiner Kindheitstage!

Oh ja, auch einer meiner Erziehungsinstanzen!
Bscht! Aber, es soll doch keiner wissen, an was ich da rummurxe!
Wie gesagt, die haben das scheinbar tatsächlich echt 25p gemacht - bis auf die VHS-Fehler.
Die ersten 2 Filme (je 3 Folgen) gehen mit meinen avs-Zeilen gut, allerdings sind die Folge-Folgen zum Teil ganz anders aufbereitet. Nicht nur, dass die TemporalSmoother-Artefakte anfangen, auch gibt's dann DotCrawls.

Didée> QTGMC bereits Overkill ...

Das ist mir eigentlich klar. Ich hab da (von dem script) auch schon einige sub-Stationen mal testweise ausgeschaltet, oder abgeschwächt. Die Rechenzeit hab ich einfach übrig (-> i2600). Ich möchte einfach sehen, was man maximal rausbekommt.
Mittlerweile sind mir allerdings die Rainbows aufgefallen und auch in den (ab Folge ~7) zT massiven "Dot Crawl"s, und dann eben diese überzogenen temporal smoothers.
Tja, es ist ein Endlosprojekt! Aber eins meiner Lieblingsprojekte, was ich nicht so - einfach so - unoptimiert codieren möchte.
Klar, das bisschen +- bitrate ist eigentlich egal, aber, wenn man schon die Rechenpower hat, warum kann man nicht noch dies/jedes mitfiltern?!
> KOFFERRADIO an Goldkontakten:
k.A. geht das billiger? Hab halt an dem besten Deinterlacer rumgewurstelt....

Propaganda> "Captain Future" (schöne Zeit) [...] Das geknacke und geknister muß sein.

Öhm, das wollte ich eigentlich rausfiltern.
Inhaltlich ist das natürlich mittlerweile schon "spaßig", wenn man sich einige Weltall-Kostruktionen, Maschinen usw. genauer anschaut, aber ich möchte doch MAXIMALE QUALITÄT haben (wo geht)! Der Captain hält das aus - und würde das gutheißen!

---
Ich muss mal schaun, ob ich ein "besseres" Sample hochladen kann.
Aber dann kommen ja noch die Flecken und Drackbatzer, die eigentlich weg gehören....

Hi!
Ich bin zurzeit an einem Teil dran - immer wieder mal, die Quelle ist so mies, dass ich bisher immer wieder aufgegeben habe.
Zumindest das Interlacing ist jetzt sauber weg, der Rest ist aber nicht wirklich "recodierbar".
Ich hab hier nen Anime (von DVD), der wirklich extremen VHS-Schmutz "drauf" hat. Auch schwimmende schwarze Ränder etc. pp. - naja.

Mein (Teil)Problem jetzt gerade:
Die haben versucht (incl. interlacing natürlich), jeglichen Schmutz mit VolleKanone-TemporalSmoother wegzubringen. :nein:
Jedenfalls hab ich jetzt in den Restframes massive Kanten-Schatten drin, die wirklich nicht zu ertragen sind. Diese Kanten-Schatten sind noch in mindestens +-3frames zu sehen! (_vor_ und _nach_ Deinterlacing, dh QTGMC ist unschuldig!)
Ich vermute, dass das ein TemporalSoften() ist. Damit haben die aber auf jeden Fall die MPEG2-Quelle total kaputt gemacht.

Kennt jemand avisynth-Tricks, mit denen man einge-/überblendete TemporalSoften-Schatten entfernen kann?
Rechenzeit ist unwichtig, wg. QTGMC läuft da eh schon alles Mögliche drüber.
Kann man nicht irgendwie:
- TemporalSmoothEN(noch stärker)
- diese Änderung extrahieren und verstärken
- von der Quelle abziehen
- QTGMC läuft je eh schon drüber (BewegungsVektoren weiter benutzen? Allerdings werden die keine +-3frames-TimeGröße beobachten; zT sogar sind sogar +4 frames sichtbar)

Grüße
shh

P.S:
Uups. Video nötig zum Ausprobieren?
Link: http://www.multiupload.com/G0620DQ2O8

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.

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):

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)?

E:\CF01PGC>\ac3fix.exe AudioFile_80.ac3 test.ac3
Starting. Input file is AudioFile_80.ac3, output file is test.ac3
Frame length is 768
Checking frame 45229: Wrong frame length, expected 34734336, got 768
Writing frame
Current wrongness is -291 bytes
Checking frame 86521: Wrong frame length, expected 66446883, got 768
Writing frame
Writing frame
Current wrongness is -102 bytes
Checking frame 131268: OK
Finished. Found bad frames. Final wrongness is -102 bytes

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....
Das ist ja ein generelles Problem beim Demux: Die ursprüngliche synch-info von A+V zueinander geht verloren.

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.

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:

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:

E:\>ac3fix.exe cf01.orig.ac3 test.ac3
Starting. Input file is cf01.orig.ac3, output file is test.ac3
Frame length is 768
Checking frame 45229: Wrong frame length, expected 34734336, got 768
Writing frame
Current wrongness is -291 bytes
Checking frame 86521: Wrong frame length, expected 66446883, got 768
Writing frame
Writing frame
Current wrongness is -102 bytes
Checking frame 131268: OK
Finished. Found bad frames. Final wrongness is -102 bytes

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?

Oje, wenn dir schon nichts mehr einfällt...
Selbst wenn man sich die separaten fields anschaut, hat man ja schon Murx. Im pan sind die schon irgendwie verblendet und in der statischen Szene flimmert's genauso.
Das Flimmern ist eine vertikale subpixel-Bewegung über ~5 frames. Sieht man zB an den Büchern neben dem TV oder der Decke neben dem Sofa(?). Die waagrechten Striche bewegen sich fein nach unten und fangen oben wieder an, bzw machen so eine Wellenbewegung über 5 frames hinweg.
Bestimmt gibt's da auch wieder irgendeinen Stabilisierer, aber das ist nicht so wichtig. Die Kinder stört das eh nicht und der TV filtert ja auch noch ein bisschen weg.
Dank' euch für's Schnipsel-Analysieren!

ReStream wird das Problem wahrscheinlich nicht richten können.
Aber die grundlegende Abfolge ist natürlich, dass beim Laden zunächst die Felder/Optionen gesetzt werden, die von der Quelldatei erkannt werden. Ändert man daran etwas, wird beim Schreiben auch nur das veränderte Feld verändert.
Die Version von ReStream kann aber keine VOBs verarbeiten und mehrere Quelldateien [automatisch] einlesen sowieso nicht. D.h. man müsste alle .m2v Teile in eine große Datei zusammenfügen.

- wenn DGIndex von der Datei nur den Bruchteil von nötigen Infos entziehen kann, ist da aber was oberfaul. Zumindest die frame-Struktur (frame/field) oder frame-Typ muss ersichtlich sein. Seltsam ist auch, dass ReStream nur ein I-frame erkennt. Es kann natürlich sein, dass dann gleich ein weiteres GOP mit einem I startet, ist aber dennoch unwahrscheinlich.
- den meisten Decodern ist die Information im sequence_header aber auch ziemlich egal, da wird einfach decodiert, was da an slices daher kommt. Könnte aber natürlich sein, dass sich da irgendeine hardware-beschleunigte Routine verschluckt.
- 540x576 gibt's in der sequence_display_extension (=dieses "Display Size: 540x576") übrigens recht oft, zumindest bei 720x576-PAL-streams. Dürfte also unerheblich sein.

Sven9, kannst du nicht ein paar MB von dem stream bereitstellen?
zB hier: http://www.multiupload.com/
Würde uns viel Raterei ersparen und wir könnten konkrete Tipps geben.

Na, "Interlace Nadeln" sind doch gut!
Wann treten die Klötzchen auf? Beim Herumspringen im Film? Wenn man den Film ganz normal abspielt, treten die Klötzchen nicht auf?

Wenn man mal von der Verblockung absieht, ist die Quelle eigentlich gar nicht so schlecht: Keine Halos, kein Ghosting[mehr] und die Farben passen auch.
Was ich jetzt noch habe ist ein Flimmern an den Begrenzungskanten/-strichen und allgemeine Unschärfe.

1. Unschärfe:
Möchte ich mit LimitedSharpenFaster() am Schluss eliminieren, falls es keine Gegenvorschläge gibt. Das produziert zwar auch leichte Halos, das Gesamtbild finde ich aber angenehmer, knackiger.
2. Flimmern:
Siehe: http://www.multiupload.com/EE4CZQKP04 [4.35MB]
Wie gesagt mit tdeint(mode=1).srestore(mode=4) "restauriert". Insbesondere nach dem horizontalen Scroll in der statischen Einstellung ist das Flimmern ziemlich eklig. Das kommt hier aber wahrscheinlich hauptsächlich vom deinterlacen. Möglicherweise ist obige Zeile doch nicht optimal.
Habt ihr da Vorschläge? Eigentlich bräuchte ich nachfolgend noch nen temporalen Blur über 2 frames, aber nur an den Begrenzungslinien und nur, wenn keine Bewegung auftritt.
Möglicherweise macht mir obiger mode=4 auch einen Strich durch die Rechnung, weil der adaptiv auch noch Nachbar-fields merged (also unregelmäßig, nicht konstant über 2 frames). Vielleicht ist der mode=2 doch besser für's Weiterfiltern: Da hätte man ein konstantes Flimmern über 2 frames und könnte die irgendwie verschmelzen...
Hmm, bin bestimmt nicht der erste, der sowas braucht - das ist ja ne Wissenschaft für sich.
3. Verblockung: Lass' ich jetzt erstmal

Hi Karl! Herzl. Dank!

Ich hab jetzt mal die hints rausgeworfen, was anscheinend noch besser läuft. Vorher waren ab und zu noch ganz feine Blends drin. So hab ich zwar noch "andere" Unschärfen, die aber seltener und weniger störend sind.
srestore(mode=2) war zwar ne Spur schärfer, aber hat leider etwas Flackern an den Kanten/Begrenzungslinien.
Für die frame-Restauration reicht hier also:

tdeint(mode=1).srestore(mode=4)

So, jetzt muss ich nur noch was zum Säubern finden...

Hi!
Ich hab schon länger nichts mehr deinterlacen müssen und bin daher mit den aktuellen avs-Filtern nicht up-to-date.
Habt ihr ne Filter-Empfehlung für folgenden Stream?
http://www.multiupload.com/PMQ4S45VGH [~15MB, wenn's zu groß ist, kann ich gerne was kleineres liefern]
Das ist ein Zeichentrick mit scheinbar periodischen interlaced und progressive-Teilen
Was am Ende für ne framerate rauskommt ist egal, "wenn's nur die Kämme und das Ruckeln ordentlich entfernt"
(Wird zu H.264 codiert, Audio wird auch recodiert)

Hi!
Nach ein weiteren Tests und Nachfragen im engl. Doom9 Forum stelle ich fest, dass ich einiges falsch gemacht habe, bzw. empfohlene Konvertierungswege einfach nicht funktionieren.
Scheinbar ist eac3to grundsätzlich für AC3 nicht zu gebrauchen:
- der input Dialog Level (zB -27dB) wird ignoriert
- es wird keine [von Dolby vorgeschriebene] DRC verwendet. D.h. der AC3-stream wird im Grunde nicht vollständig decodiert.
- wenn man AC3 encodiert wird einfach ein Dialog-Level von -31dB gesetzt, was in den meisten Fällen auch falsch ist

Ersteres könnte man mit der -4dB Option (bei -27dB) von eac3to richten.
Zweiteres kann man aber gar nicht mehr richten, weil kein decoder von einem AAC oder MP3, FLAC, WAV... am Ende noch weiß, dass für die Datei eigentlich noch eine DRC angewendet werden muss. Also wird damit gar nichts gemacht und man hat viel zu viel Dynamik, zu leise Dialoge usw... man muss ständig am Receiver rumstellen, um den Sound irgendwie passend zu bekommen.

Naja, ich muss mal schaun, was azid so liefert.
Wäre mit eac3to ja zu schön gewesen: demuxen/transcoden von Audio, alles flott in einem Rutsch...

Vielen Dank für die ausführliche Beschreibung der ganzen Problemstellen!

Zitat

Dein Problem, wenn du AC3 und AAC vergleichst, ist wohl vor allem, dass der AC3-Decoder im A/V-Receiver die Lautstärke anders aussteuert als der PC...

Hast Recht, der Vergleich bringt schonmal nichts. Ich werd' wohl nicht drumrum kommen, etliche streams auf dem AV-Receiver zu vergleichen.

Das mit der Dialog-Normalisierung war mir im Grunde schon klar. Komisch ist nur, warum eac3to mit und ohne -keepDialNorm gleichlaute Dialoge produziert. Zumindest am PC hört sich das aber bei allen decodern richtig an.
Die Dialoglautstärke war aber am Receiver aber eigentlich auch nie das Problem. Ich muss bei AAC (bzw dem PCM-MultiCh von der Mediabox) nur so stark aufdrehen, dass das ich schon ordentliches Grundrauschen bekomme.
D.h. ich müsste nur die Gesamtlautstärke vorm Encodieren anheben und alles wäre ok?
Hmm. Aber vielleicht interpretiere ich das hier schon falsch, weil der Dialog eigentlich zu leise encodiert wurde und wenn ich am Receiver aufdrehe, bekomme ich nur ein passendes "Gesamt-Hörbild", weil die DRC die anderen Kanäle kompensiert...?

Hauptproblem am AV-Receiver ist dann also die unterschiedliche Verstärkung pro Kanal, bzw unterschiedliche DRC pro Kanal je nach eingeschaltetem feature wie zB "Nachtschaltung", "Film-Modus" etc.
Argh! Ich stelle gerade fest, dass hier auch dieses Audyssey Dynamic Equalizer und Dynamic Volume aktiv ist (Onkyo TX SR507). Zumindest bei letzterem optimiert der ständig den Dynamikumfang.

Zitat

Wenn Mehrkanalton direkt ohne Verstärkung decodiert wird, dann kann das Ergebnis leicht "zu leise" werden...

Das was wirklich zu leise ist, ist das AAC von eac3to. Der decodiert aber mit libav/ffmpeg und laut changelog ohne DRC (bei v2.11: "* libav AC3 decoding added (without DRC)"; später keine Meldungen, dass DRC jetzt dabei wäre). D.h. eac3to ist auf jeden Fall der falsche Weg, weil nicht einmal das von Dolby für die Wiedergabe vorgeschriebene DRC verwendet wird. Und die DRC brauche ich vor dem Encodieren schon angewendet, weil ich im Receiver schon mal eine gleiche Basis brauche, bevor die ganzen anderen Verstärker/Kompressoren aktiv werden.

Also muss ich auf jeden Fall azid verwenden, da das zumindest das DRC auf die Kanäle anwendet.
(oder ist hier vielleicht diese "Boost"-Funktion besser? Die macht doch Gain+DRC, oder?)

Bleibt noch die Gesamtlautstärke.
OTA PreGain (mit azid+DRC:Normal) ist am PC (auf 2ch) jedenfalls viel zu laut, ich muss mal schaun - äh hören, wie laut das am Receiver ist.
Aber bei AC3 5.1 -> 2ch-PCM war eine 100% Normalisierung auch immer schon zuviel. Da hab' ich bisher immer 94% verwendet. Da muss ich wohl ausprobieren, welcher Level etwa gleich dem vom AC3 ist.

Hmm, oder ich könnte meine Mediabox mal einstellen auch AC3 auf PCM-MultiCh zu decodieren und dann die Ausgabe mitschneiden und Pegel vergleichen... Hat das vielleicht schon mal jemand gemacht - und mir die Arbeit abgenommen?

Letztlich müsste sich aber eine default-Verstärkung finden lassen. Beispielsweise: Unverändertes AC3 bei Lautstärke 30 = PCM mit +5.7dB + DRC:Normal, oder?
(wenn das +5.7dB clipping verursacht, dann soll er halt nen zweiten pass machen)
Oder bin ich da auf dem Holzweg?

Grüße...

Hallo!

Ausgangsmaterial ist ein "normaler" AC3 5.1 stream wie er etwa auf allen möglichen DVDs zu finden ist. eac3to sagt dazu zB:

Zitat

AC3, 5.1 channels, 0:05:00, 448kbps, 48khz, dialnorm: -27dB

Wenn ich jetzt an der HiFi-Anlage nichts rummurxe (DRC unverändert), decodiert mir die eine bestimmte Dynamikbandbreite, wie sie von Dolby für die Decoder vorgesehen ist.

Jetzt habe ich schon alles mögliche probiert (denke ich), ich bekomme aber mit dem NeroAAC keinen AAC 5.1-stream hin, der die gleiche Dynamik und Lautstärke wie der AC3-stream auf der Anlage hat. Da ich noch keine Anlage kenne, die AAC direkt dekodieren kann, bzw selber keine habe ;), heißt das also, dass der AC3-stream gleich dem PCM-Multichannel-stream sein soll. Soweit ich weiß, gibt's bei AAC keine Dynamikoptionen, sodass zumindest der decodierte PCM-stream vom AAC immer gleich sein sollte. Ich muss dem NeroAAC also eigentlich nur "passende" Multichannel vorsetzen, richtig?
Wie wäre denn dafür der richtige Weg?

Ich verwende bisher immer den MPC+ffdshow zum testen. Als AC3/AAC-decoder wird aber laut graphedit der "DTV-DVD Audio Decoder" von Win7 verwendet)
An der HiFi-Anlage hängt ne Mediabox dran, die AC3 unverändert und AAC als PCM-MultiCh weitergibt.

Meine Versuche bisher (mit MPC):
1. eac3to: Das ist immer "zu leise". (-keepDialNorm macht auch keinen Unterschied? Zumindest im MPC)
2. besweet via BeLight:
- Azid:Normal + OTA "PreGain" ist zu laut im MPC
- Azid:Light|Normal|Heavy ohne OTA hören sich alle drei etwa gleich an, aber Dialoge sind immer noch leiser als im originalen AC3

Bei NeroAAC nehme ich ne vbr-Qualität von 0.30; der schaltet dabei auch SBC ein:

Zitat

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format-Version : Version 4
Format-Profil : LC
Format-Einstellungen für SBR : Ja
Format-Einstellungen für PS : Nein
Codec-ID : 40
Dauer : 5min 0s
Bitraten-Modus : variabel
Bitrate : 212 Kbps
maximale Bitrate : 280 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz

Alles anzeigen

Wahrscheinlich macht mir hier auch der MPC einen Strich durch die Rechnung, oder mein Gehör, oder meine nur 2ch am PC... Was mache ich falsch? Was wäre denn ein geeigneter Weg, die Dateien am PC zu vergleichen?

Grüße...

Neue Version: v3.3.0
Herzlichen Dank Mosu!

homepage: http://www.bunkus.org/videotools/mkvtoolnix/
source-code: http://www.bunkus.org/videotools/mkv…x-3.3.0.tar.bz2
Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkv…3.3.0-setup.exe
http://www.bunkus.org/videotools/mkv…nicode-3.3.0.7z

Changelog:
2010-03-24 Moritz Bunkus <moritz@bunkus.org>

* Released v3.3.0.

* Build system: Sped up builds by using pre-compiled
headers. Patches by Steve Lhomme (see AUTHORS) and myself.

2010-03-23 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Fixed the default duration for interlaced
MPEG-1/2 video tracks. Also added the 'interlaced' flag for such
tracks. Patches by Xavier Duret (see AUTHORS). Fix for bug 479.

2010-03-22 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Specifying a FourCC with spaces at the end
will not result in an error anymore. Fix for bug 480.

2010-03-19 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Timecodes for MPEG-1/2 tracks are calculated
properly, especially for B frames. Patch by Xavier Duret (see
AUTHORS). Fix for bug 475.

2010-03-18 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: enhancement: Added a message in verbosity level 2 to
the splitting code. It reports before which timecode and after
what file size a new file is started.

* All: A lot of changes preparing mkvtoolnix for use with the
upcoming libebml2/libmatroska2 versions were applied. Patches by
Steve Lhomme (see AUTHORS).

2010-03-15 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Fixed a crash when reading Matroska files
that contain Vorbis audio with in MS compatibility mode (CodecID
A_MS/ACM). Fix for bug 477.

* All: enhancement: Added support for old Mac-style line endings
(only '\r' without '\n') in text files.

2010-03-11 Moritz Bunkus <moritz@bunkus.org>

* mmg: enhancement: Added the values "4483M" and "8142M" to the
"split after this size" drop down box.

2010-03-06 Moritz Bunkus <moritz@bunkus.org>

* mmg: bug fix: Fixed compilation if gettext is not available.

2010-03-03 Moritz Bunkus <moritz@bunkus.org>

* Build system: Added project files and fixes for compilation with
Microsoft Visual Studio 8. Patches by David Player (see AUTHORS).

* Installer: bug fix: A couple of start menu links to pieces of
the documentation were broken. Added missing start menu links to
translations of the documentation.

* mkvmerge: bug fix: The SRT reader skips empty lines at the
beginning of the file.

2010-03-02 Moritz Bunkus <moritz@bunkus.org>

* Build system: bug fix: Fixed the configure script and compilation
on OpenSolaris.

2010-02-26 Moritz Bunkus <moritz@bunkus.org>

* Installer: bug fix: The "jobs" directory in the application data
folder is removed during uninstallation if the user requests
it. Fix for bug 474.

* mkvextract: bug fix: Fixed granulepos calculation when
extracting Vorbis tracks into Ogg files. Fix for bug 473.

2010-02-24 Moritz Bunkus <moritz@bunkus.org>

* All: bug fix: The programs will no longer abort with an error
message if a selected interface translation is not available. The
"C" locale is used instead. Fix for bug 472.

2010-02-23 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge, mkvextract: enhancement: Improved the error resilience
when dealing with damaged Matroska files. When a damaged part is
encountered reading will continue at the next cluster.

2010-02-20 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Fixed the handling of UTF-16 encoded chapter
names in MP4/MOV files.

2010-02-18 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: enhancement: Some Matroska files contain h.264/AVC
tracks lacking their CodecPrivate element (e.g. files created by
gstreamer's muxer). For such tracks the CodecPrivate element (the
AVCC) is re-created from the bitstream. Fix for bug 470.

* mkvmerge: bug fix: MP4 files that do contain edit lists but
whose edit lists do not span the entire file are processed
properly. Such files are created by current x264 builds. Fix for
bug 469.

2010-02-13 Moritz Bunkus <moritz@bunkus.org>

* Build system: Fixed configure for systems on which 'echo' does
not support the '-n' parameter (e.g. Mac OS).