Beiträge von Naito

    Da stimme ich dir uneingeschränkt zu. Persönlich nutze ich --preset eher selten, da es für meine Ansprüche zu unflexibel ist und stattdessen meist -V, bei dem ähnlich wie bei --preset auch einige Voreinstellungen übernommen werden.

    Ansonsten würde ich ebenfalls einfach "--preset standard" empfehle zu nutzen, wenn man mit LAME einfach "nur" benutzen möchte (also ohne groß herumzutesten, sondern schnell ein Ergebnis erzielen, das auch Qualitativ gut ist).

    PS: Für mich ist "-V" einfach schon in Fleisch und Blut übergegangen, da übersehen ich leider unabsichlich die --presets. :redface:

    Nein, noch nicht. Könnte aber eine interesant Alternative zu FAAC für AAC-HE sein / werden.

    Aus dem Changelog:

    Code
    mp4tools (0.2) unstable; urgency=low
      * Replaced real's encoder with an opensource, better one
     -- Matteo Croce <rootkit85@yahoo.it>  Tue,  6 Jun 2006 18:44:48 +0200


    Und was ich persönlich sehr interessant fand:

    Zitat

    aacplusenc (0.15) hardy; urgency=low
    * Full 64 bit support
    -- Matteo Croce <rootkit85@yahoo.it> Wed, 23 Jan 2008 20:14:58 +0100


    64Bit-Support für einen Encoder sieht man auch nicht überall.

    Wenn jetzt noch der Klang schöner ist, als der von FAAC, kann man ihn bestimmt weiterempfehlen.

    EDIT: Maximal 64kbps so wie ich es auf der HP gelesen habe. AAC-HEv2 selbst kann auch Mehrkanalton, ist also eine Beschränkung des Encoders.

    Reichen CBR 192 kbps grundsätzlich aus ?


    Kann leider nur für VBR sprechen, aber dort wurde in einem Listening Tests von HA gezeigt, das schon 128kbps für die meisten sehr nahe an der Transparenz ist. Wenn du also nicht gerade die Extraklasse-Boxenausstattung in deinem Auto und schwer zu encodene Musikstücke hast, sollten auch schon 128kbps bei LAME (!) reichen. Einfach mal mit einer CD-RW testen, ob du einen Unterschied hörst (und auch gleich VBR mit ;) ).

    Wie auch schon erwähnt, wird eher eines der "-V"-Presets empfohlen; falls VBR möglich ist..

    seit neustem kann ich in den settings den haken bei "open preview after avisynth ..." nicht mehr entfernen? ist das jetzt voreingestellt? mich nervt das einfach nur. hab die version 0.3.0.1020.


    Wurde wegen eines Bugs bzgl AR so festgelegt. Ist in einer der späteren Versionen behoben.

    Bei MeGUI 3.x kann man die Profile über File -> Import Presets installieren (siehe auch den Link von Selur). Das einfache kopieren in den passenden Profilordner klappt anscheinend nicht mehr (was auch immer Sie sich dabei gedacht haben...)

    (gibt es da eigentlich auch so einen Zusammenhang oder kann man wenn man will auch 48kHz Material mit 36kBit/s encoden?)


    Ich hab es mal fix mit BeLight getestet. AC3@5.1 44kbps@48kHz -> AAC@5.1 32kbps@48kHz mit NeroAacEnc geht. Ich wüsste auch keine Grund, der dagegen sprechen würden. Komischerweise kommt aber trotz "-cbr 32" ein VBR heraus, mit ~40kbps (lt. MediaInfo). Versteh allerdings nicht warum (abgesehen davon, das jeder Kanal nur ~11kbps bekommen hat. Denn so hört es sich auch an. :zunge: ) Persönlich stört mich an dem Punkt VBR weniger, da ich NeroAacEnc eh nur mit "-q" nutze...

    Das mit dem RAW Audio als Input und konvertieren geht mit mencoder gar nicht, der kann Audio nur konvertieren, wenn er in einem Container zusammen mit einer Videospur steckt. :) (Wurde auch schon öfters in der Mailingliste angesprochen, aber die Mencoder Leute meinen dann nur, dass es halt so wäre und man ja andere Tools nehmen könnte. :[)


    Argh, wie **** ist das denn... :motz:
    Gibt es vllt. einen Hack, der diese FAAC-Beschränkung aufgeben kann? Dann könnte man sich zur Not einen so angepasstes Build selbst kompilieren. Oder ist das ein "größeres" Problem?

    BePipe kenne ich, da ich aber das ganze möglichst gleich unter Linux und Windows machen will fällt es flach. ;)


    Das einzige Tool, das ich noch kenne, dass unter Linux und Windows verfügbar ist, wäre ffmpeg. Allerdings bräuchte man dann auch Builds, die faac mit eingebaut haben.

    Ansonsten wäre meine einzige Idee: mencoder raw-audiostream | faac encoding | mencoder muxen (oder bspw. gleich in mp4box, wenn es MP4 werden soll). Keine Ahnung ob es klappt, aber Versuch wäre es wert. Allerdings müsstest du dann wieder ein zusätzliches Programm/Libary nehmen...

    Hmm, das Samplingrate und Bitrate in direktem Zusammenhang stehen ist soweit verständlich. Höhere Samplingrate -> mehr Audioinformationen -> mehr benötigte Bitrate. Aber warum er die Bitrate "festschreibt", kann ich auch nicht verstehen. So wie ich das auf der Mailingliste verstanden habe, scheint das nur vorzukommen, wenn man aus dem Video heraus das re-encoding vornimmt. Nicht aber, wenn man das Audio demuxed. Ist das bei dir ebenfalls so? Wenn ja, würde ich eher auf eine Bug in Mencoder schließen. Vllt. ließe sich das Audio demuxen und per Pipe neu an FAAC weiterreichen. Ist zwar umständlicher, aber vllt. klappt es so.

    Bzgl. pipen: Kennst du BePipe? (enthalten in BeHappy) Damit lassen sich per Pipe AviSynth-Skripte an CLI-Programme übergeben.

    PS: Ich muss gestehen, das ich FAAC (weil er qualitativ leider nicht so gut ist wie NeroAacEnc) noch nie benutzt. :redface:

    Meines Wissens wird auf HA zum Vergleich in den Listing Tests VBR New genommen, das allein ist für mich Vertrauensbeweis genug. Ansonsten lässt sich ja bspw. mit foobar2000 recht schnell auch auch Blindhörtest machen. Und da kannst du dann am einfachsten entscheiden, ob VBR New passend ist, oder nicht. "Problemsample" finden sich in der eigenen Sammlung bestimmt einige. ;)

    Nein, schlechter geworden ist er nicht. Aber auch, wie Brother John bereits sagte, nicht weltbewegend besser. Er hat eher noch ein weniger mehr "Feinschliff" bekommen.

    Was ist das für ein Quellfilter und woher bekomm ich den bzw. wie mach ich es dem Programm klar, das er diesen benutzen soll?


    Das BASS-Plugin kann AAC-Dateien für AviSynth verarbeitbar machen.

    Gibt es villeicht auch eine Möglichkeit bei mehreren audio streams in einer Video Datei die gewünschte auszuwählen ohne diese demuxen zu müssen?
    Denn Megui wählt standardmäßig den ersten aus.


    Hmm, einfach die gewünschte Audiospur vorher im Quell-Container als erste setzen?

    Wie LigH schon sagte: Mit BeHappy gibt es eine GUI, die dir AAC-Encoding anbietet.

    Oder du schreibst einfach ein AVS-Skript, in dem du die AAC-Datei mit dem BASS-Plugin öffnest. Dieses AVS kannst du auch an MeGUI als Input geben, und das Encoding funktioniert.

    Welche Qualitätseinstellung welche AAC-Variante ist, hab ich auch im Wiki verewigt. :D
    Was genau passt, findet man meinst nur durch ein paar Tests heraus. Auch ob einem AAC-HE zusagt, oder doch es lieber AAC-LC sein sollte.

    Bei meinen Test, die allerdings schon einige Zeit her sind, hatte der neroaacenc ungefähr ein Channelcuppling von 3,5. D.h. 192kbps@5.1 / 3,5 = ~55kbps@2.0 (denke aber nicht höher als bei der von LigH genutzten √5-Berechnung, die ich persönlich übrigens auch super als Daumenregel finde :daumen:) Für die meisten normalen Leute sollte spätestens bei 128kbps@2.0 kein hörbarer Unterschied zwischen Original und Komprimierten Material sein.

    MP3 selbst bietet mit ID3 ja eine Möglichkeit zusätzliche Meta-Informationen zu speichern. Denkbar wäre zum Beispiel auch eine Lösung mit Synchronised lyrics oder Lyrics3. Mit ein wenig Hilfe mit der Suchmaschine deines Vertauens solltest du auch leicht Programme finden, die dir bei Unterstützen zu Erstellung solcher Lyrics behilflich sein können. Jedoch muss auch der Player diese "Features" implementiert haben. (IDv2.3 sollte inzwischen aber recht verbreiten sein und kann durchaus als "Standard" angesehen werden. Anders sieht es da mit ID3v2.4 aus.)

    Ich werf' mal als Alternative zum Intels Atom VIAs neuen Nano ("Isaiah") in den Raum. Mit dem VX800-Chipsatz soll auch H.264-Decoding möglich sein. Der TDP liegt zw. 5W (U2300 1,0GHz) und 25W (L2100 1,8GHz). Wann der allerdings kommt ist noch unklar. Testberichte sind mir auch noch nicht bekannt.

    Ein Gain ist ja keine normale Normalisierung mehr, sondern nimmt immer einne bestimmte Anzahl von Frames des Files und gleicht diese individuell an, so dass das evt leise Passagen hochgezogen werden und das ganze "fülliger" klingt und lauter erscheint.


    Nein. Meines Wissens macht das eine Dynamikkomprimierung.

    ReplayGain bringt alle Musikstücke auf eine einheitliche Lautheit (Standard: 89db). Eine Normalisierung hebt den Pegel auf 0db (Maximum ohne Clipping). Aber das ist nur die Lautstärke im Audiofile selbst. Wenn du Intro und Stück beide Normalisiertst (auf 0db), können sie trotzdem noch unterschiedlich laut sein. Nach einer Gain-Analyse, werden beide aber eine Lautheit von 90db haben. (Die Dynamik bleibt dabei erhalten.)

    Lautstärke = intern, innerhalb eine Audiofiles
    Lautheit = extern, wahrgenommene "Lautstärke"

    Ich habe 2 Musikstücke, wobei das erste das Intro des zweiten ist, also das zweite das eigentliche Stück. Das erste ist nur ein Windrauschen, das zweite die Musik. Beim ersten Stück könnte ich das ganze um 60% erhöhen, weil es recht leise ist, das zweitge Stück lässt noch 20% zu. Wenn ich jetzt beide seperat normalizieren lasse, heisst das das er das erste Stück um 60%, und das zweite um 20% erhöhen würde. Es würde aber dann nicht mehr so zu einander passen, weil das verhältnis nicht stimmt. Ich brauche also ein Programm mit einer Funktion, die beide Files untersucht und erkennt, das der höchste Pegel noch 20% zulässt und beide dann auch nur um 20% erhöht.


    Könnte man dann nicht einfach Intro und Stück hintereinander schneiden und dann normalisieren? Oder verstehe ich etwas falsch?