Parameter -i und -no-delay im QAAC-Encoder

Zu "-i":
Ein wave-Header beschreibt, wie lang eine wave-Datei ist. Ohne "-i" hält sich qaac an diese Angabe und hört mit der Encodierung auf, sobald die angegebene Länge erreicht ist. Das kann zu Problemen führen, wenn:
- das wave-erzeugende Programm den Header falsch schreibt
- eine Datei sehr lang ist, weil die Länge je nach wav-Format stark begrenzt ist. Bei einem 3-Minuten-Song ist das irrelevant, bei einem 200 Minuten 5.1-Film kann es aber passieren, daß die wave-Datei länger wird, als die Längeangabe im Header.
Falls es zu einem dieser Probleme kommt, merkt man das recht deutlich daran, daß der Ton auf einmal mitten im Film aufhört.
Meine Empfehlung: immer "-i" benutzen, damit man auf der sicheren Seite ist.

Zu "--no-delay":
Du sagst, Du hattest ohne "--no-delay" "keine Probleme". Ich sage: Du hattest möglicherweise Probleme, ohne es zu wissen. Die Delays von AAC-Encodern liegen üblicherweise in einer Größenordnung von 50ms, d.h. Du hast es möglicherweise nur nicht gemerkt, daß eine leichte Asynchronität entstanden ist.
Meine Empfehlung:
- wenn Du Musik-Singles oder Alben als reine Audiodateien für Deinen iPod o.ä. encodieren willst: NICHT --no-delay nutzen
- wenn Du die Tonspur für einen Film encodierst, der nachher in eine MKV-Datei soll: immer --no-delay nutzen
(für Filmton in MP4 gibt es elegantere Lösungen, das kommt ein bißchen auf den Player/Muxer an. Dort kann man in l-smash z.B. das Encoder-Delay explizit angeben. Wenn Du es einfach halten willst, schalt das Encoder-Delay auch für MP4 ab)

Bei Stereo sollte das Problem auch noch nicht so leicht auftreten, aber bei 5.1-Mehrkanalton passiert es bei langen Spielfilmen durchaus ab und zu. In einer herkömmlichen WAV-Datei laut Microsoft RIFF-Standard mit 32-bit-Chunks kann man maximal 4 GB an Sampledaten speichern (wenn die Längenangabe ohne Vorzeichen interpretiert wird). So kann man also zurückrechnen:

4'294'967'296 Bytes : 6 Kanäle : 2 Bytes/Kanal (16 bit integer) : 48000 Samples/Sekunde (DVD-Samplingrate) : 60 Sekunden/Minute ~ 124 Minuten = 2:04 h

Sollte ein Programm die Längenangabe auch noch unsinnigerweise mit Vorzeichen behandeln, dann wäre schon nach der Hälfte, also 1:02 h, Schluss mit Ton.

Um dies zu vermeiden, hatte Sonic Foundry (heute aufgekauft von Sony) das WAV64-Format entwickelt, in dem für Längenangaben 64 bit verwendet werden, damit kann (ähnlich dem Unterschied zwischen FAT32 und exFAT oder NTFS bei Dateisystemen) bis weit über Terabyte-Größen gespeichert werden. Das WAV64-Format ist mittlerweile relativ weit verbreitet, aber nicht jedes Programm unterstützt es.

Ähm, ich möchte das Thema nochmal aufgreifen da ich beim encoding des Audio-Teils meiner Serien doch einen merklichen Versatz habe.
Dieser liegt aber in Größenordnung bei -250ms !
Na jedenfalls sagt die "Command Line Options" Seite von qaac64.exe:

Zitat

--no-delay Compensate encoder delay by prepending 960 samples
of scilence, then trimming 3 AAC frames from
the beginning (and also tweak iTunSMPB).
This option is mainly intended for resolving
A/V sync issue of video.

... wenn mich mein Englisch nicht komplett verlassen hat heißt das doch das hier 960 samples (Silence) Delay noch vorne-drann geklebt und dann wieder 3 AAC Frames gekappt werden - nur die Sample Zahl ist doch variabel pro AAC Frame oder ?!

Wie soll man denn da ein korrektes "Delay" hinkriegen ?

Nicht ganz... Es werden 960 Samples Stille vorn angefügt, damit der Encoder die erstmal mit encodiert und sich sozusagen "einarbeitet"; anschließend werden die überzähligen drei AAC-Frames vorn beim Speichern des Ergebnisses aber wieder weggelassen.

Ob das nun in deinem Fall einen Versatz korrigiert oder verschlechtert, wirst du wohl ausprobieren müssen. Vielleicht liegt es auch an ganz anderen Ursachen (z.B. eine Serien-DVD nicht korrekt per PGCs gerippt, sondern die VTS wie auf DVD verwendet, in denen dann vielleicht noch extra Schwarzbilder vor jeder Folge enthalten sind, um die DVD-Navigation im Authoring abzusichern).

Zitat von may24

nur die Sample Zahl ist doch variabel pro AAC Frame oder ?!

Nein.

Ansonsten stimme ich LigH zu: die 250ms Versatz kommen nicht von QAAC, das hat andere Ursachen.