HeadAC3he delaywert

Stimmt nicht. Der delay wird ms genau beachtet für alle targets außer "source" und "ac3-wav". ac3 frames sind halt 32ms lang (bie 48kHz).

Liegt daran, dass bei "Target: Source" die AC3-Datei blockweise geschnitten wird, ohne sie zu decodieren; bei den anderen Zielformaten wird zunächst nach PCM decodiert (übrigens in einem Fließkommaformat, um höchste Auflösung während der gesamten Bearbeitung zu sichern), und da kann man dann an jedem Sample schneiden (z.B. jede 1/48000. Sekunde).

Mal ne Frage dazu.
Ich hab nen Audiostrean mit besispielsweise 100ms Delay.
Wenn ich mir nun diesen Stream mit HeadAC3he neuencodieren lasse, und HeadAC3he den Delaywert richtig erkennt, hat dann der neu erstellte Stream ein Delay von 0 ms oder immernoch 100ms?
Der Delay wird ausgeglichen und beträgt nun 0 ms, oder?

:ja: So ist das:

HeadAC3he erkennt (übrigens aus dem Dateinamen!), ob in der Quell-Tonspur etwas zu viel oder zu wenig ist, und schneidet ab oder füllt auf. Das Ergebnis nach der Konvertierung ist dann ohne Versatz synchron, wenn der Versatz im Dateinamen der Quelldatei korrekt drin stand.

Hi,

Zitat

Mal ne Frage dazu.
Ich hab nen Audiostrean mit besispielsweise 100ms Delay.
Wenn ich mir nun diesen Stream mit HeadAC3he neuencodieren lasse, und HeadAC3he den Delaywert richtig erkennt, hat dann der neu erstellte Stream ein Delay von 0 ms oder immernoch 100ms?
Der Delay wird ausgeglichen und beträgt nun 0 ms, oder?

----------

Zitat

So ist das:

HeadAC3he erkennt (übrigens aus dem Dateinamen!), ob in der Quell-Tonspur etwas zu viel oder zu wenig ist, und schneidet ab oder füllt auf. Das Ergebnis nach der Konvertierung ist dann ohne Versatz synchron, wenn der Versatz im Dateinamen der Quelldatei korrekt drin stand.

also ich habe immer gedacht time delay bleibt in ziel format enthalten weil wenn ich mit headac3he eine ac3 datei mit 80ms in mp3 format encode und später mit gknot muxen möchte, gknot erkennt dennoch die time delay exakt wie von der quelldatei !
muss ich in gknot die gezeigte audio timedelay auf 00 setzen oder ist richtig so was er anzeigt ?

Noch mal:

Auf der DVD wurde die Tonspur gegen das Video verschoben, damit sie synchron wird (also Geräusche zum Bild passen - hätte man die Tonspur zum selben Zeitpunkt wie das Video beginnen lassen, dann wären Bild und Ton asynchron gewesen).

Der Ripper bzw. Demultiplexer erkennt, dass Video und Audio zu verschiedenen Zeiten beginnen, und schreibt diesen Unterschied in den Dateinamen der Audiodatei (andere einfache Möglichkeiten, sich den Versatz zum Video zu merken, gibt es ja kaum).

HeadAC3he und BeSweet können - wenn gewünscht - diesen Versatz ausgleichen, während sie die Tonspur konvertieren; das Ergebnis wird dann zur gleichen Zeit wie das Video starten dürfen/müssen.

Um nun zu vermeiden, dass das nächste Programm nochmal einen (jetzt ja nicht mehr vorhandenen) Versatz aus dem Dateinamen liest, muss man natürlich im Namen der Zieldatei nun jeden Hinweis auf einen Versatz entfernen.

Ja ich gebe zu, der Dateiname beim Zielformat sollte intelligenterweise den richtigen delaywert widerspiegeln. Zur Zeit ist das aber bei HAC3 nciht der Fall.

aha alles klar danke für hinweis