neues Spielzeug

    Zitat

    Dank hans-jürgens aufmerksamen Ohren konnte ich in der Tat das Problem mit dem letzten frame bei AAC beheben und auch das channel mapping sollte nun OK sein.Habe immer noch keine Optionen bei AAC implementiert. Ich habe vergessen das Datum und die Version bei HAC3 anzupassen, aber naja...habe die ac3enc auch dazugepackt, da ich die unter Win neu kompiliert habe.

    Jo, geht alles - channel mapping ist korrekt, kein Müll mehr am Ende, die neue AC3.dll funktioniert auch. :) Zu den geeigneten Optionen habe ich ja schon einiges geschrieben, aber falls noch Fragen sind, nur zu... Kann man eigentlich so etwas wie Presets anbieten? Das wäre in HeadAC3he nämlich praktisch, weil man ja auch einen Resampler dabei hat, der sehr nützlich ist, wenn man noch weiter mit der durchschnittlichen Bitrate heruntergehen möchte. Dann sollte man nämlich den AC3-Input auf 24 kHz downsamplen und FAAC mit -q 90 oder -q 100 benutzen (siehe auch den schon erwähnten Thread auf Doom9.org). Hast Du eigentlich vor, HeadAC3he mal als Linux-Version anzubieten, da es einen guten Audio-Transcoder für dieses OS noch wohl nicht gibt (siehe den anderen Thread im Linux-Forum auf Doom9.org)?

    Zitat

    hans-jürgen
    Übrigens funkt bei mir die lame ohne Probs. Wird wohl ein Problem mit dem Intel compiler sein. Kannst dir ja mal den M$ compiler ziehen (gibts ja jetzt kostenlos) und selbst probieren die lame.dll zu übersetzten. Die auf meiner site ist eh uralt.

    Ich habe mir inzwischen von RareWares das LAME-Paket v3.96 geholt und die enthaltene lame_enc.dll mit HeadAC3he getestet - alles klar, kein Absturz mehr.
    <!-- / message --><!-- attachments -->

    Bzgl Linux: Siehe erste Seite des Threads. Mir ist Linux mittlerweile *wichtiger* als Windows, nur ist die Zeit der begrenzende Faktor. HeadAC3he an sich wird es nicht als natives linux binary geben. Wenn dann schon was von Grund auf neues und besseres. Aber mittels wine sollte HeadAC3he schon unter inux laufen. Tut es bei mir.

    Presets werde ich nicht anbieten, ich denkde das wäre eher der Job von FAAC, aber du kannst das Problem umschiffen, indem du dir die Einstellungen als eigene INI Datei speicherst (du solltest allerdings kein file geladen haben). Bei Bedarf lädst du danndie INI Datei. Besonders schlau wäre es dann alle ünnötigen Paramter aus jenen INI Dateien zu entfernen, damit die anderen Parameter nicht verstellt werden.

    Downsampler: SSRC

    Optionen kommen noch... Die Motivation bei mir ist extrem niedrig bei dem GUI Zeugs herumzufuschen...

    Übrigens fehlt leider die Samplerate 24 kHz in der Dropdown-Liste fürs Resampling, was mit 48 kHz Quelldatei und FAAC bei -q 100 (dem Default-Setting) eine ideale Kombination ergäbe, da FAAC dann den Cutoff automatisch auf 12 kHz begrenzt. Eigentlich beherrscht ja SSRC auch diese Samplerate (z.B. in foobar2000), kannst Du das vielleicht noch in HeadAC3he "nachrüsten"?

    Mit den möglichen GUI-Optionen könntest Du Dir auch mal foo_faac.dll angucken, wo das effektiv und gut gelöst wurde. Am wichtigsten ist eine Auswahlmöglichkeit der VBR-Qualität in Prozent und vielleicht noch die ABR-Bitrate für Leute, die die genaue Dateigröße bestimmen müssen, alles andere ist Zugabe (z.B. das Outputformat MP4/M4A usw.). Deshalb hat FAAC selbst auch keine Presets und wird sie wahrscheinlich auch nie haben, weil die Default-Werte plus variablem -q reichen. Die Preset-Idee für HeadAC3he kam mir nur im Zusammenhang mit dem Resampler, aber der Vorschlag mit der INI-Datei ist natrülich auch eine Alternative.

    Bin nun dabei die Optionen für FAAC reinzufrimeln.

    Habe aber ne Frage bzgl der bitrate Option: Ist diese überhaupt nötig? Diese aktiviert ja AFAIK einen ABR Modus, nur ist dieser im unteren bitrate Bereich anzusiedeln. Die sourcen (->frame.c) verraten, daß man nicht wesentlich über 76kbps/ch hinauskommt.

    Also, wie sinnvoll ist der ABR Modus oder soll ich ihn weglassen und nur den Quantisierungsparameter zugänglich machen?

    Da ja HeadAC3he vorwiegend von DVD-Rippern genutzt wird, die vor dem Brennen der CD(s) gerne die exakte Größe des Audiotracks bestimmen wollen, brauchen sie im allgemeinen ein CBR- oder ABR-Setting. Dafür (und fürs Streaming via mp4live vom MPEG4IP-Projekt) ist diese Option gedacht. Andererseits kann man auch durch Ausprobieren und Lesen der Wiki-Tabelle herausfinden, mit welcher VBR-Einstellung man zur gewünschten Dateigröße/Bitrate kommt, was ich auch eher empfehlen würde, da der VBR-Modus nun mal bei Video-Soundtracks besonders effektiv arbeitet und besser klingen wird. Ich überlasse es also Dir... ;)
    <Radio Eriwan/>

    Die Tabelle für die Bestimmung der ABR im Sourcecode ist eigentlich veraltet bzw. müßte mal angepaßt und erweitert werden, insbesondere die dazugehörigen Cutoff-Frequenzen, da sie bei Werten unter 64 kbps/ch zu früh absenken und darüber stets bei 16 kHz bleiben (individuelle -c Settings sind aber auch mit ABR möglich).

    Übrigens habe ich noch einen kleinen Fehler entdeckt, wenn man nach Wählen des AAC-Formats die Quelldatei auswählt und das Zielverzeichnis nicht ändert. Dann wird nämlich über die rot eingefärbte geschätzte Dateigröße und auch über eine anschließende Fehlermeldung angezeigt, daß angeblich kein Platz mehr auf dem Laufwerk wäre. Erst wenn man statt auf Start auf Play klickt und die WAV-Datei abgespielt wurde, kann man das Encoden starten.

    Oh, ich weiß gar nicht, ob ich bei der Berecnung der Dateigröße AAC berücksichtige...daher könnte der Fehler herrühren.

    Naja, mal gucken, was ich mache.

    Zitat von hans-jürgen

    Da ja HeadAC3he vorwiegend von DVD-Rippern genutzt wird, die vor dem Brennen der CD(s) gerne die exakte Größe des Audiotracks bestimmen wollen, brauchen sie im allgemeinen ein CBR- oder ABR-Setting. Dafür (und fürs Streaming via mp4live vom MPEG4IP-Projekt) ist diese Option gedacht. Andererseits kann man auch durch Ausprobieren und Lesen der Wiki-Tabelle herausfinden, mit welcher VBR-Einstellung man zur gewünschten Dateigröße/Bitrate kommt, was ich auch eher empfehlen würde, da der VBR-Modus nun mal bei Video-Soundtracks besonders effektiv arbeitet und besser klingen wird. Ich überlasse es also Dir... ;)


    hm, die audio größe ist beim rippen eigentlich ziemlich egal, da normalerweise als erster schritt der audio stream (mit dem der gewünschten qualität entsprechenden setting) enkodiert wird
    und im zweiten schritt die größe des video streams and die des, bereits erstellten, audio streams angepasst wird und nicht umgekehrt!

    dh die angebotenen settings fürs audio enkodieren sollten daher die sein, welche die beste qualität bieten (ich nehme mal an CBR fällt damit auf jeden fall weg)
    => VBR und/oder ABR

    Ich weiß, daß ich nichts weiß (Sokrates)

    So, eine neue Version:

    - diverse GUI fixes/Änderungen
    - Einstellungen für FAAC (bitte Testen, insebsondere Vorschläge für hardcoded default)
    - vorbis.dll wurde anders kompiliert: umbenannt in hVorbis.dll und fungiert nur noch als wrapper, dh ist gegen die *offizielle* vorbis.dll, ogg.dll, vorbisfile.dll gelinkt, so daß man ohne Probs alternative compiles benutzen können sollte. Die beigefügten Datein sind aus den cvs vor etwa 2 Wochen oder so.
    - mehr sampling Raten für SSRC

    noch nicht gemacht:
    - bitraten Schätzung FAAC für VBR (link für mich?) und dementsprechend Angabe des geschätzten Plattenplatzes

    Zitat

    - diverse GUI fixes/Änderungen

    Eigentlich könnte man noch AAC als Source File ermöglichen (mit libfaad2.dll), sogar WMA wie z.B. die neue winLAME-Version (über die basswma.dll).

    Zitat

    - Einstellungen für FAAC (bitte Testen, insebsondere Vorschläge für hardcoded default)

    Die Defaults sollten sein:

    * LC-Profil (SSR gibt es in FAAC nicht, nur in FAAD2, soweit ich weiß),
    * ADTS-Header (raw sollte man eigentlich gar nicht anbieten weil mißverständlich),
    * VBR-Qualität sollte noch ein Prozent-Zeichen bekommen und für Video-Soundtracks eher bei 75% liegen (= ~230 kbps/6ch),
    * außerdem ist der Minimalwert 10% (klingt aber grausam, deshalb eher 50% als untere Grenze empfehlenswert,
    * Bitrate für den ABR-Modus gilt jetzt für alle Input-Kanäle insgesamt (nicht mehr pro Kanal), deshalb Werte von 10-448 kbps/6ch oder mehr theoretisch sinnvoll (praktisch wegen interner Beschränkung auf ca. 76 kbps/channel begrenzt),
    * wenn "Min." bei der ABR-Einstellung "Minimum" bedeuten soll, wäre eher "Maximum" oder "Average" richtig,
    * der Lowpass sollte bei 16 kHz liegen, nicht bei 20 kHz,
    * die "Short Blocks"-Option ist eher für Testzwecke gedacht (genau wie "raw AAC") und sollte weggelassen werden, da man damit auch viel falsch machen kann.
    * Interessanter wäre wahrscheinlich noch MP4-Output (auch als Default) neben AAC ADTS, weil manche Filemuxer keine AAC-Dateien erkennen (z.B. MP4Box) und Apple auch nicht.

    Zitat

    - mehr sampling Raten für SSRC

    Neben den jetzt vorhandenen 24 kHz wäre vielleicht noch 48 kHz sinnvoll, falls jemand aus irgendeinem Grund beim Transcoding auf diese Rate upsamplen will.


    Zitat

    - bitraten Schätzung FAAC für VBR (link für mich?) und dementsprechend Angabe des geschätzten Plattenplatzes

    Ich habe heute die Tabelle auf der Wiki-Seite für FAAC erneuert, aus der Du gängige Schätzungen für eine Stereo-Testdatei (16bit, 44.1 kHz) ablesen kannst (auch mit Downsampling). Einen Test speziell mit einer 5.1 AC-3 Quelle ("Lord of the Rings II" Trailer) und mehreren VBR-Settings findest Du über den entsprechenden Link im Text unter der Tabelle:

    http://www.audiocoding.com/wiki/index.php?page=FAAC#three

    Achtung - Upsampling: Die SHIBATCH.DLL, die in BeSweet verwendet wird, war zum Upsampling von 44100 nach 48000 Hz nie recht brauchbar; DSPguru hat jedenfalls bisher keine Lösung dafür, dass es in dieser Richtung bei manchen knirscht. Die SSRC.EXE jedoch kann WAV => WAV ordentlich upsampeln.

    hans-jürgen

    Danke für die Infos, nur soviel erst mal:

    faad2 kommt wegen GPL Lizenz nicht in Frage, WMA juckt mich herzlich wenig (was ist das? :D). Wenn jemand irgendein gescharetes dixv Schrott file transcodieren will, ist das nicht mein Problem...

    Ich werde die Optionen nicht beschneiden, nur um Dummies vor Fehlentscheidungen zu schützen. Das muß jeder selbst wissen, was er macht, darum werde ich nciths rausnehmen, was schon drin ist.

    mp4 weiß ich nicht, da ich für libmp4 nicht soviel sinnvolles gefunden habe. GPL oder LGPL?

    Für upsamplimng müßte ich an der SSRC rumfrickeln. Weiß nciht, ob ich dafür Zeit finde. Im übrigen steht es jedem coder frei, mir dabei zu helfen, da die sourcen auf meiner Seite liegen...dabei könnte auch mal auf die neueste Version geupdatet werden.

    Zu den bitraten guck ich das mal an, ob ich das sinvolle Schätzungen abliefern kann.

    Nimm es mir nicht übel, wenn cih nach einer zweiten meinugn bzgl aac defaults frage, denn mir scheinen deine Ansprüche was den Sound angeht nicht allzu hoch zu sein. (Wobei mir persönlich es schleierhaft ist, wieso man 5.1 ac3 auf 5.1 aac transkodieren will, habt ihr keinen anständigen DD Verstärker??)

    Im übrigen ncoh eine Ankündigung vorweg: Ich werde sobald ich meine neue Version als (semi-)stabil freigebe, *keine* ICC compiles mehr auf die Seite stellen, da ich zum einen keine Zeit und keine Lust habe und ich nicht den aktuellen ICC 8.0 für Win habe. Ich habe auch überlegt die dlls evtl *nur* als Sourcen anzubieten, damit sich jemand anders um die Pflege derer kümmert. Das würde mir etwas Ballast abnehmen.

    So, da wohl niemand sonst Vorschläge unterbreitet, werde ich wohl HansJürgens AAC Preset übernehmen.

    Übrigens, habe ich mal mit ac3enc rumgespielt:

    Die gute Nachricht: Ich konnte es beschleunigen (ohne Qualiverlust), so daß es nur noch 89% der ursprünglichen Zeit auf meinem Rechner brauchte.

    Die schlechte Nachricht: Die dll wird es "nie" geben, da ich gegen eine GPL lib linken müßte.

    Genauer: Ich habe die mdct Routine durch fftw ersetzt, nachdem ich in einem Wiki gefunden habe, wie man die DCT-IV für MDCT benutzen kann. Steve Johnson (einer der FFTW Leute) hat mir sogar code geschickt, der von fftw generiert worden ist und sogar noch etwas schneller sein soll, als wenn ich die dct-iv mit vorheriger Anpassung der Daten benutze. Er hatte einen ähnl COde bereits mal den Vorbis Leuten gegeben (siehe Vorbis Archiv). Diesen COde habe ich ncoh nciht getestet.

    Interessant ist, daß ich FFTW noch nicht mal im tuning Modus getestet, sondern im "estimate" Modus. Da ist noch was drin...

    Schade schade... :)


    Ach ich vergaß: Ich habe das nicht mir Headac3he sondern nativ unter Linux getestet. Ist ja kein Akt ac3enc ausführbar zu machen und mit PCM Daten zu füttern...

    So, habe auch mal an SSRC rumgespielt. Die FFT ROutine hierdrin ist schon ziemlich gut, habe ich festgestellt. Mit ESTIMATE war FFTW auch nicht schneller, aber als ich den optimieren ließ, (abzüglich Optimierungszeit, aber das könnte man einmal machen und dann nie wieder...) konnte ich die Zeit auf 92% runterbringen, wobei hier noch übel rumkopiert wird zwischen datenstrukturen, dh. hier ist noch etwas drin.

    Bei ac3enc habe ich mal den Profiler drüberlaufen lassen und festgestellt, daß der Autor wenig gute Datensrtrukturen gewählt hat. Indem ist 4 ushort ints auf int umgestellt hatte, hatte ich schon abermals 3% weniger Ausführungszeit und ich denke, da wären immer noch einige % drin, wenn man den Rest auf 32 bit umstellt. Der Athlon mag nämlich 32bit am liebsten bzw keinen Mischmasch aus verschiedenen Typen.

    Coder sollten mal bei AMD sich das Dok zeihen, wo erklärt wird, wie man seinen Code für den Athlon am besten schreibt (ich denke Intel Proz würden auch davon profitieren). Mit einigen einfachen Regeln kann man schon einige % "geschenkt" bekommen...

    Zitat von DarkAvenger

    Darum bin ich besonders an reports von Linux usern interessiert, wie HeadAC3he mit Wine ausführen wollen. Wine user sollten die M$ TT Schriften installieren, sonst sieht die GUI nach nichts aus..D A


    Hähm... du entwickelst unter Linux es soll aber mit WINE laufen???
    Schmeiss den Windows-Code überboard und mach gleich richtig native unter Linux. Ansonsten ist es auch nix weiteres als ein WindowsProg, das unter mittels Wine unter Linux ne WIndows Umgebung vergauckelt bekommt. Unter Wine läuft ja auch CCE mit Linux...

    Aber ansonsten eine gute Idee... Es braucht mehr gute Tools für Linux!

    See Ya
    Bitspyer

    Der Weg zur Dunklen Seite... Schneller er ist, verführerischer, leichter.

    Lesen...

    Windows code über board schmeißen ist nicht einfach. Es lohnt nicht HeadAC3he zu portieren (grauenhafter code). Lieber start from scratch, dann aber richtig. Dazu wäre wxWidgets prädestiniert.

    Probier mal die 0.23b Version und die letzte alpha Version unter Linux zum Laufen zu bringen. Du wirst den Unterschied sehen. :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden