Beiträge von Naito

    DirectShowSource kann durch Überblenden (wie in ConvertFPS) aber ein CBR-Video erzeugen:

    DirectShowSource (string filename, float "fps", bool "seek", bool "audio", bool "video", bool "convertfps", bool "seekzero", int "timeout", string "pixel_type")

    Nicht schön, aber wenigstens verarbeitbar.


    Das habe ich auch vor, jedoch bekomme ich bei "convertfps=23.976" (mit und ohne "fps") folgende Fehlermeldung:

    Zitat

    Script error: the named argument "convertfps" to DirectShowSource had the wrong type (Sample.avs, line 2)

    deaktiviere mal:
    ffdshow->Video decoder configuration->Ausgabe->Nur zu kompatiblen Filtern verbinden


    Hat leider nicht gehofen. :(

    Ich hab gerade auch ein WMV probiert, das klappt ohne Probleme.

    Ich möchte eine MP4 per DirectShowSource() laden, leider klappt das aus einem mir unbekannten Grund nicht.

    ffdshow Beta4 + neuster Haali Media Splitter sind installiert. Mit dem MPC lässt sich das ganze auch ohne Probleme abspielen (WinXPSP2, keine Patches).

    PHP
    LoadPlugin("F:\Programme\AviSynth\plugins\DirectShowSource.dll")
    DirectShowSource("J:\Sample.mp4", logfile="J:\Sample_ds_log.txt", logmask=35)
    Zitat von Fehlermeldung

    DirectShowSource: Could not open as video or audio

    Video returned: "DircetShowSource: couldn't open file J:\Sample.mp4: Schnittschtelle wird nicht unterstützt"

    Audio returned: "DircetShowSource: couldn't open file J:\Sample.mp4: Schnittschtelle wird nicht unterstützt"

    Richtigerweise würde ich den H.264-Stream mit Yamb demuxen und dann mit DGAVC indexieren. Da es sich hier jedoch um VFR handelt, ist das leider nicht möglich.

    Es ging ja nicht um eine vollständige Liste... eher ne Liste mit "roten Links" (für noch nicht existierende Artikel). ;)


    Eine Auflistung der "roten Links" gibt es unter "Spezialseiten" -> "Gewünschte Seiten".
    Vorsicht ist bei "Falschnamen" oder Synonymen geboten. Es gibt noch keine "einheitliche Richtlinie" welche Namen den Artikelnamen stellen, und welche die Weiterleitung werden. Wird von Fall zu Fall entschieden, war bislang auch noch kein Problem (Weiterleitungen machen es möglich ;)).

    Fände ich gut. Siehe auch Paralleldiskussion.


    Ich würde sagen, wir reden hier über das Wiki und in der Paralleldiskussion über das Forum und germanDoom9 ;)
    ___


    Angedacht ist, das Stickies in Form von bspw. FAQs in das Wiki übertragen werden, und dann dann nur noch sehr wenige Stickies existieren, die auf das Wiki verweisen. Somit sollte es keine Doppelarbeit geben.

    Und das Wiki ist auch als "Wissensarchiv" gedacht. Es geht auch nicht darum, der Wikipedia Konkurenz zu machen. Wir besprechen hier viel speziellere Theme, und dafür wird auch ein spezielleres Wiki benötigt. Aber es mangelt, wir ihr richtig erkannt habt, an Mitarbeitern. Dieses Problem wurde schon einmal besprochen. Hier gibt es viel Potenzial, und einen Teil meines Wissen, habe ich schon in das Wiki übertragen. Aber mein Wissen ist begrenzt. Wenn nur drei oder vier Leute die Artikel schreiben, ist das halt schwer. Ich bin jedoch davon überzeugt, das sobald eine "kritische Masse" an Artikel im Wiki sind, es auch mehr Beteiligung geben wird. Persönlich wünsche ich mir einige Artikel im Wiki. Doch bis die kommen können, fehlt es mir noch an Wissen, bzw. einige kann ich gar nicht schreiben. Ich bin sehr dankbar für jeden, des sich einbringt. Tot ist das Wiki nur, wenn wir es sterben lassen.
    ___

    Gleitz Meinung zu den Schritt-für-Schritt-Anleitung kann man natürlich teilen oder nicht. Ich persönlich gebe mir Mühe, auch keine "Komplettlösungen" (z.B. Brother Johns Encodingwissen, sehr starkes Beispiel) zu schreiben. Eine Art Guide habe ich trotzdem Geschrieben: Die Installationsaleitungen für BeSweet/BeLight. Und meiner Meinung nach geht das völlig konform mit dem, was Gleitz aussagen wollte.
    ___

    Warum Guides unerwünscht sind, hat Gleitz in den ersten Beiträgen erläutert.

    Jetzt müßte man erstmal nachschaun, wie MeGUI AC3s decodiert ( kein DirectShow ). Ging das dort nicht über AviSynth (+ Plugin) und der Umleitung per Pip ? Evt. ist das Uralt/Fehlerhaft etc?


    Die Codebasis des MeGUI-Audio-Encoder ist die von BeHappy. Wenn ich mich nicht irre benutzt das NicAudio. (plus ein paar Pipe-Spielereien)
    ___

    So, ich kann das Problem jetzt näher eingrenzen: Habe die Datei nochmal in Cuttermeren geöffnet, und man sieht, dass an den problematischen Stellen jeweils der Ton zwischen 2-Kanal und 5.1 umschaltet. D.h. die .ac3 Datei ist eigentlich in 5.1 Ton, allerdings ist an den Schnittstellen immer noch ein wenig vom 2-Kanal Ton übriggeblieben.

    Kann man das irgendwie in den Griff bekommen? Ich würde die Datei nur ungern weiter beschneiden, da sonst der Videoschnitt nicht mehr stimmig ist...


    Ich selbst nutze nicht Cuttermaran, sondern MPEG2Schnitt und kann dazu leider nicht viel sagen (hatte die Probleme noch nicht).

    Da du später sowieso in AAC wandeln möchtest, könntest du zu Not eine "Holzhammmer"-Methode verwenden. Mit Hilfe von BeSweet/BeLight die "vermurkste" AC3 mit Nero-AAC-CLI in AAC encoden. Falls das nicht klappt, dann mit Zwischenschritt einer PCM-Datei (WAV). Ob es klappt weiß ich nicht. Und ob das deinen Qualitätsansprüchen genügt musst du selbst entscheiden (im Gegensatz zum Arbeitsaufwand des Ton-genauen-Schneidens).

    Eine Suche Wert wäre es auch auf HydrogenAudio, dort wurde das Thema schon des öfteren diskutiert. Mir ist bekannt das das Nero Digital Audio-Team intern Software für die Tests an ihrem AAC-Encoder nutzt, ich weiß aber nicht genau welche. Und wenn mich mein Gedächtnis nicht ganz trügt gibt es glaube ich auch eine genormte Analysesoftware (die allerdings nicht ganz aktuell ist, was die internen Modelle angeht).

    Über Sinn und Zweck dieser Software lässt sich wie immer streiten. ;D
    ___

    Wie LigH schon erwähnt hat sind Blindhörtests die heutzutage gängige und allgemein anerkannte Praxis um eine Aussage über die Qualität (v.a. Transparenz) eines Audiocodecs zu treffen. Neben dem ABX- gibt es auch noch das ABC/HR-Verfahren (mit Rating). ABX lässt sich bspw. sehr einfach mit foobar2000 machen.

    Eine Übersicht einiger Listening Tests findest du hier. (Bitte die unterschiedlichen Versionen der Encoder beachten!)

    Meine persönliche Meinung:

    Lossy:

    • AAC
    • MP3
    • Vorbis
    • WMA

    AAC, da es mit Mehrkanalsound derzeit am "besten" umgehen kann. MP3 sieht zwar auch Mehrkanalsound vor, eine Codec-Umsetzung ist mir aber nur in vorm von AudX bekannt (das Tot ist, bin mir auch nicht sicher ob es Standardkonform war). Vorbis als freier Audio-Codec und WMA wegen der Marktmacht von Kleinweich.

    Lossless:

    • FLAC
    • Monkey Audio
    • WavPack


    Hier ist die Wahl eher eine Frage des persönlichen Geschmacks. :D (Geschwindigkeit, Hard-/Software-Unterstützung)

    Eine aussagefähige Umfrage (über 2.500 Stimmen) findest du bspw. hier.

    Doch, klar hab ich da schon bestimmte Vorstellungen, also bis jetzt habe ich folgende Kriterien eingeplant: Encoding-Dauer (Tests auf mehreren PCs), Datei-Größe, Effizienz der Komprimierung (im Vergleich zum benötigten Speicherplatz auf einer CD) und der hörbare Qualitätsverlust (beim Anhören auf Lautsprecher/mit Kopfhörer etc.)... und das alles natürlich mit verschiedenen Bitraten/Qualitätseinstellungen bei den jeweiligen Formaten.

    • Encoding-Dauer: Dazu hat LigH sich ja schon geäußert. Dem kann ich mich nur anschließen.
    • Datei-Größe: Verhält sich umgekehrt proportional (?) zu Qualität
    • Effizienz der Komprimierung: Wie willst du das messen? Dafür würde man ein konstantes Qualitätsmaß benötigen, und dieses bei Audio-Encodern festzulegen ist mehr als kritisch.
    • hörbare Qualitätsverlust: Wieder eine, wie ich finde, recht subjektive Sache. Vllt. Messbar mit ABC/HR, bitte mit Kopfhörern.
    • mit verschiedenen Bitraten/Qualitätseinstellungen bei den jeweiligen Formaten: Da hast du dir aber einiges vorgenommen. :D

    Ein Test/Vergleich von lossless ist recht einfach, hier kann man auf reine "Performance" gehen da die Qualität konstant bleibt. Bspw. Geschwindigkeit, Dateigröße (Komprimierbarkeit),... bei den jeweiligen Qualitätseinstellungen. Zu beachten ist, dass auch wirklich lossless herauskommt, einige lossless-Encoder können auch "Hybrid". Und das ist nicht 100% lossless (lässt sich leicht bspw. mit Hilfe der Doku oder eines Hash-Vergleiches herausfinden). Für eine Statistische Aussage müssen es mindestens 30 Samples sein, besser mehr (~120).

    Ein Vergleich von lossy-Formaten ist, finde ich, sehr schwierig. Als Grundlage für mich würde die erreichbare Hörqualität stehen. Doch um diese zu ermitteln sind umfangreiche Test nötig. Es gibt passende Software, die so etwas messen kann (siehe hier), jedoch sind diese Verfahren recht umstritten. Eine subjektive Qualitätsmessung benötig eine hinreichend kritische Masse (mind. 30 Personen). Aufgund der Subjektivitä ist eine fundierte Aussage "Format A ist bei x kbps qualitativ gleichwertig zu Format B bei x kbps" ebenfalls nicht einfach. Auch verhält sich das Qualitätsniveau nicht linear (Vorbis nutzt bspw. unterschiedliche Joint-Stereo-Verfahren für Unterschiedliche Qualitätsabschnitte. Ganz zu schweigen von "Feintuning" am Psychoakustischen Modell aller lossy-Encoder). Desweiteren wird für eine ausreichenden Statistischen Grundlage ca. 30 unterschiedlichen Samples benötigt.
    ___

    Gute Informationsquelle (neben uns ;))

    • HydrogenAudio.org DIE englische Audio-Community. Großteil der Entwickler der gängigsten Audio-Encoder sind dort vertreten (Zitierfähig?)
    • Wiki von HydrogenAudio Sehr Informativ,
    • AudioHQ Deutsche Audio-Community. Schwerpunkt auf Lossless.

    Bekomme ab und zu "The server is too busy at the moment. Please try again later." oder "Database error" beim doom9-Forum. Kann das jmd. bestätigen? Und falls ja, weiß vllt. jmd. woran es liegt. (Wartungsarbeiten?)

    damit ich den zwischenschritt mit wav auf die platte schreiben umgehen kann.?


    Ja, so meinte ich das. Ich weiß vom Nero-CLI-Encoder, dass er Pipes unterstützt. Da ich aber meist GUIs benutzte kenne ich mich da nicht so aus. (Dimzon hat ein Tool geschrieben, das "BePipe" heißt, dass vllt. für dich interessant sein könnte.)

    Die Entwickler meinten, 2pass lohnt sich höchstens bei sehr langen Audiomitschnitten (Oper, Konzerte, ...). Für alles andere ist "-q" völlig ausreichend.
    ___

    Sorry wenn ich jetzt eine Grundsatzdiskussion lostrete:

    ich bin hier gerade dabei einige Music CD´s auf dem PC zu archivieren...

    Derzeit ist die Frage in welechen Codec ich das mache.

    FLAC: Ist mir zu groß


    Persönliche würde ich nicht AAC sondern gerade FLAC nutzen.

    Wie ja bekannt, gibt es entweder verlustbehaftete oder verlustlose Komprimierung.
    FLAC, WavPack, APE, TTA, TAK sind verlustlos. MP3, AAC, Vorbis, Ghost,... sind verlustbehaftet.
    Wenn du also eine Langzeitarchivierung machen möchtest raten ich dringend zu einem lossless-Codec. Von diesem kannst du immernoch und jederzeit in ein lossy-Format wandeln. Und was die Platz angeht: 0,25€ / GB ist das für mich auch jeden Fall Wert.

    PS: Ich bereue es heute noch, das ich manche CD's als MP3s und nicht als FLAC archiviert habe. In mein Archiv kommt nur noch FLAC! Vllt. bin ich auch einfach zu Audiophil. :D

    Zu dem HE:
    Dein (und AliceDs) Artikel "AAC Encoding und MP4 muxing HowTo" liest sich so, als wäre HE bei 6-Kanal-Audio generell besser als LC. Außerdem wird erwähnt dass HE bei niedrigen Bitraten besser ist als LC.


    Naja, als generell besser würde ich AAC-HE gegenüber AAC-LC nicht bezeichnen. HE kann durch SBR die benötigte Bitrate reduzieren. Es ist allerdings Geschmackssache, ob man das mag. (Ich persönlich höre z.T. SBR-Artefakte, AliceD hat das nicht so gestört).

    Meine persönliche Empfehlung: Entscheide dich für eine bestimmte "Zielbitrate" und setze die Qualität entsprechend (bspw. "-q 0.40").
    Ein erzwingen von HE (oder auch LC) ist nicht empfehlenswert. Ersichtlich wird dies vllt. am bestem in diesem Post.

    Bei 6 Kanälen mit 224 kbps bleiben (jetzt mal rein rechnerisch) ca. 37 kbps pro Kanal. Das würde ich jetzt durchaus noch als 'niedrig' bezeichnen wenn man davon ausgeht dass es bei mp3s mindestens 160 kbps (80 pro Kanal) sein sollten und ich schon AC3-Audio mit 640 kpbs gesehen habe.


    Stimmt leider nicht ganz. Wenn man von "True Stereo" ausgeht, dann ist 160 / 2 = 80kbps je Kanal. Da moderne Encoder jedoch Mide/Side-Stereo verwenden, kann man nicht direkt sagen, welcher Kanal wie viel Bitrate bekommt.
    Für 5.1 lässt sich als Faustregel sagen, dass es ungefähr die 3,5-fache Qualität von Stereo benötigt. Bsp: 224 kbps / 3,5 = 64 kbps; deine AAC hat ungefähr das Qualitätsniveau einer 64kbps-Stereo. (Das es das 3,5- und nicht das 5-fache ist, "bewirkt" das Channelcuppling)

    Habe auch schon vorher einige Videos mit AAC-HE Audio gehört (video? hören? egal!).
    Die waren rein von meinem Gefühl her nicht schlechter als AC3.


    Wenn das für dich OK, dann immer zu. Aber warum nicht die AC3 behalten. Auf einer DVD ist meist genügend Platz.