MP3 zu AAC

1.) Ja, das ist normal. Bei AAC, MP3, Vorbis, AC3 etc. verlängern sich Prinzipbedingt die Tonspuren am Anfang und Ende etwas. Das am Anfang kann man versuchen wieder wegzuschneiden (vor oder nach dem Encoding) ("encoder delay")
2.) Mußt Du letztendlich selbst entscheiden, aber bei bisherigen Vergleichen hat der Apple-Encoder tatsächlich sehr gut und die ffmpeg-Teile (gibt verschiedene) eher schlecht abgeschnitten. Unter Windows nutze ich gerne eine Pipe um das Demuxen zu sparen - weiß nicht, welche Möglichkeiten es da auf dem Mac gibt.

Angemerkt sei auch, dass neuere qaac Versionen (ab 2.1.2) auch eine Option namens '--no-delay' haben:

Zitat

--no-delay will compensate encoder delay (2112 samples) by prepending silence of 960 samples before sending input to encoder, then trimming 3 AAC frames at beginning (2112 + 960 = 3072 = 1024 * 3, where 1024 is the frame length of AAC. So total amount of delay will be exactly equals to length of 3 AAC frames). Note that these numbers are doubled in case of SBR.

This option is meant for video as a mean to resolve A/V sync issue. The resultant AAC will have exactly zero-delay, but might have pops/clicks at the beginning. Use with care.

welche den Encoderdelay 'beseitigt'.

Cu Selur

Zitat

weiß nicht, welche Möglichkeiten es da auf dem Mac gibt.

Mac kann pipe und named pipes nutzen. (wie unter linux mittels mkfifo)

zu qaac: Das ist 'Windows only'. afconvert wäre eine alternative dazu auf dem Mac.
Leider akzeptiert afconvert so weit mir bekannt keinen pipe input. (geht vielleicht mit named pipes; das hab ich noch nie versucht :))
Falls

Zitat von Lupurus

Entsteht dieser Delay denn in gleichen Teilen am Anfang und am Ende?

Nein, die sind unterschiedlicher Natur. Aufgrund der Natur der Audiocodecs (MDCT) entsteht am Anfang eine Verzögerung. Die zusätzliche Länge am Ende ensteht dadurch, daß viele Codecs mit festen Paketlängen arbeiten, also z.B. ist ein Paket immer 20ms lang. Wenn das am Ende nicht zufällig aufgeht, muß halt der Rest von 20ms noch mit Stille aufgefüllt werden. Deshalb kann man das auch nicht einfach anhand der Länge errechnen.

Manche Encoder erlauben es, das Delay von vorherein auszugleichen, ansonsten muß man Nacharbeiten. Teilweise ist es recht einfach, da einige Encoder immer dasselbe Delay verwenden. Apple AAC-LC z.B. immer 2112 Samples.

Zum Verständnis kannst Du mal http://forum.gleitz.info/showthread.php…ht-mit-MKVMerge und die dort verlinken Threads lesen.

Zitat

Entsteht dieser Delay denn in gleichen Teilen am Anfang und am Ende?

Der Delay entsteht am Anfang.

Zitat

Habe mir ein kleines Bash-Skript geschrieben, welches die Differenz der Dateien ausrechnet (lese es mit mediainfo aus). An sich könnte ich ja jetzt den gewünschten Teil dann über ffmpeg abschneiden.

k.A. wie verlässliche MediaInfo da bei der Längenangabe ist,... (vermute nicht besonders, zu bedenken ist, dass man die Länge der RAW Streams ermitteln muss und die Länge die Im Header steht vermutlich nicht stimmt :))

Die Länge auszurechnen bringt eh nichts, da:
Delay + alte Länge + Padding == neue Länge

Eine Gleichung mit zwei Unbekannten und ohne eindeutige Lösung (bzw. mit unendlichen vielen Lösungen).

Zitat von Lupurus

Was bedeutet denn 2112 Samples? Haben die eine bestimmte Länge, die man ausrechnen kann?

Anzahl an Samples / Samplerate = Delay
z.B.
2112 Samples / (48000 Samples/Sekunde) = 0,044 s = 44ms

Zitat von Lupurus

Mir kam gerade die Überlegung, dass ich ja am Ende gar nichts abschneiden muss, wichtig ist ja nur der Anfang.

Genau.

Zitat von Lupurus

Eine andere Frage noch: Das Ausgangsmaterial hat eine CBR von 192kbps. Ist es grundsätzlich besser, eine CBR beizubehalten, oder auf VBR zu wechseln?

VBR ist in der Regel zu bevorzugen. Ob CVBR oder "true" VBR ist meist nicht soo entscheident - bei einem Vergleichstest schnitt Apple CVBR ein kleines bißchen besser ab als TVBR.

Beide LC? Beide dieselbe Samplingrate? Mag auch vom Encoder abhängen, ob es konstant ist.