Beiträge von DarkAvenger

  • Lohnt Downsampling von 48 kHz auf 44100 Hz?

    Zitat von Kika

    Na ja, so kann man das nicht stehen lassen. Was einen Sinus betrifft, klar, den kann man restaurieren, aber Musik? Niemals, dazu ist das viel zu komplex.


    Das ist der klassische Denkfehler. Musik besteht aus mehreren Frequenzen. Wir reden aber nur davon eine bestimmte Frequenz zu digitalisieren. Dafür reichen aber in der Tat 2 Samples im Abstand von max der halben Periode aus.

    Denk mal drüber nach.

    Du kannst dir deine komplexe Musik als Superposition von Frequenzen ansehen (->FT) und daraus resultiert das gesagte.

    Was den Rest deiner Aussage angeht: Du hast meinen Teil bzgl Amplitude also verstanden. :)

  • Lohnt Downsampling von 48 kHz auf 44100 Hz?

    Zitat von Kika


    Die maximale Tonfrequenz bei einer Samplingfrequenz von 44.1 kHz ist 22 kHz - und auch das nur theoretisch, denn nur 2 Samples pro Schwingung würde ich nicht mehr als "Ton" bezeichnen... ;)

    Genau die 2 Samples reichen aber aus - vorausgesetzt dein DAC arbeitet vernünftig, dein Ton (wir reden von einer Sinusschwingung bestimmter Frequenz) wird durch mehr samples nicht besser. (wenn der DAC natürlich Rechteckwellen erzeugt generierst du Frequenzen, die nicht vorhanden waren.) Nur das die gewünschte Amplitude besser getroffen wird, wird wahrscheinlicher.

  • neues Spielzeug

    Man achte auf das Log in HeadAC3he.

    Die alten Versionen laden eine "vorbis.dll". Diese ist eine veränderte CDEX Vorbis.dll - nicht zu verwechseln mit der vorbis.dll von der offiziellen SDK. Hier ist alles in der dll drin

    Die neuen Versionen (ich glaube seit 0.24 irgendwas) laden eine hVorbis.dll. Diese ist eine umbenannte (verän. CDEX) vorbis.dll, wo ich allerdings den backend raus genommen habe, so daß ich bei updates von Vorbis, die dll nicht neu erstellen muß. Man tauscht einfach die vorbis.dll (Achtung, jetzt die aus dem SDK), ogg.dll, etc aus... In den neuen Versionen funktionieren die speziellen für HAC3 gemachten vorbis.dll (also s.o.) nicht mehr. Evtl gehts noch, wenn man diese einfach in hVorbis.dll umbenennt. Ich bin mir allerdings nicht mehr ganz sicher, ob ich am ABI was geändert habe. Aber wieso will man noch die speziellen verwenden, wenn es doch mit den offiziellen klappen sollte...

    Nun bei daphy sollte doch eine komplette 024-a13 liegen, oder? Ebenso hat 0.25-a3 alle selbst gestrickten dlls.

  • neues Spielzeug

    Theoretisch sollten beim Vorbis support alle offiziellen compiles funktionieren. Du brauchst nur die hVorbis.dll, diese ist gegen die offiziellen gelinkt. Du mußt nur aufpassen, womit die jeweiligen dlls kompiliert wurden. Bei ICC brauchst du evtl noch libmmd.dll oder so.

  • neues Spielzeug

    Naja, das mp3 decoding Problem ist immerhin confirmed. Nur wie ich LigH scho sagte, werde ich erstmal nicht weiter nach dem Problem suchen, sondern gucken,d aß ich HeadAC3he nativ unter Linux übersetzen kann. So kann ich wieder sinnvoll debuggen, insbesondere mit der Hilfe von valgrind.

  • AC3 Encoder, Vergleich, Analyse.

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Hmm, habe mal kurz in den Source geguckt. ATH scheint der encoder doch schon zu benutzen ("/* compute masking curve */"). Aber Psychoakkustik sehe ich nicht. Um die Bitrate zu erreichen, wird einfach solange mehr quantisiert (also SNR abgesenkt), bis man beim target ist - so lese ich den Code inlk Comments, wenn ich den überfliege. Naja einleitender comment:

    Code
    /*
 * The simplest AC3 encoder
 * Copyright (c) 2000 Fabrice Bellard.
 *

    OK, dank Ausnutzung von ATH, ist das aber etwas untertrieben ;)

  • AC3 Encoder, Vergleich, Analyse.

    Nicht ganz. Die Specs, die erhältlich sind, sind für einen Dekoder. Rückwärts aufgebaut, hast du einen simplen encoder -> ac3enc...

    Prinzipiell könnte man daher einen genauso simplen DTS encoder bauen. FAAC als aac encoder ist genauso simpel aufgebaut.

    Nru zur Verdeutlichung: ac3enc und faac verhalten wohl in der möglichen Quali analog einem mp3 iso Referenz code entsprechend. (Nicht falsch verstehen, daß ich deren Quali mit mp3 vergleichen wollte...) Wenn man nun bedenkt, daß alte xing encoder besser also der iso code waren, aber der xing codec immer noch grottig war, so kann man sich ausmalen, was aus ac3enc noch herauszuholen wäre, wenn man den analog lame aufpolieren würde...

    Umgekehrt zeigt es die Stärker des Verfahrens an sich, daß man schon ohne "Tricks" zu respektablen Ergebnissen kommt.

  • AC3 Encoder, Vergleich, Analyse.

    Ich habe *nicht* behauptet, ac3enc hätte ein psychoakk. Modell. Im Gegenteil, ich denke eher nicht, zumindest ist mir nichts derartiges in den Sourcen aufgefallen.

    Jedenfalls bestätigst du meine Theorie, daß eine "Verbesserung" im Grunde nur mit Wegschmeißen erreicht wird

  • AC3 Encoder, Vergleich, Analyse.

    Naja, die -400db wären ja normalerweise sehr schön, doch wenn das original nur ~ -100db hat, muß doch "something fishy" sein. Wobei ich ehrlicherweise mit dem noise level Wert nicht viel anfangen kann. Im Grunde sollte es doch sein, daß solange der Wert nicht über dem original liegt, wurde kein Rauschen hinzugefügt. Wenn der Wert doch dadrunter liegt, wurde was weggeschmissen? Man kann doch den Rauschlevel nicht künstlich ohne weiteres verbessern, oder?

    tedgo

    Daß die käuflichen besser sind liegt bestimmt auch daran, daß die ein psychoakk. Modell haben, was ac3enc meines Wissen nach nicht hat. Nur bei Rauschen sollte das eigentlich nichts ändern. Aber so ein tiefgehender Experte bzgl AC3 bin ich nun auch wieder nicht...

  • AC3 Encoder, Vergleich, Analyse.

    Hmm, interessant daß THD und IMD+Noise bei "meiner" dll um den Faktor 10 niedrieger sind als bei den originalen. Ich denke, das liegt an der Änderung zu etwas tiefgreifenderen Benutzung von floating points im Vgl zur original Implementation, die integerbasiert ist.

    tedgo

    Kannst du dieses Resultat subjektiv bestätigen, daß ac3 encodes mit hac3 weniger "rauh" klingen?

  • AC3 Encoder, Vergleich, Analyse.

    Zitat von katjarella


    Ich frag mich allerdings nur, warum bei den freien Encodern nix weiter einzustellen ist, wie zb bei hier. Ich habe jetzt richtig Angst mal ne echte mehrKanal zu encoden.

    Naja, die meisten Parameter sind auf einfache defaults einstellbar bzw einfach ermittelbar. Wo ich mich schon etwas mehr frage, was Sache ist, ist bei der Kodierung der DRC Faktoren. Keine Ahnung, ob der Encoder da etwas sinnvolles macht.

    Evtl willst du das auch mal testen:

    Einen Stück Filmsoundtrack nehmen, den im Original durch verschiedene DRC Stufen dekodieren (evtl auch mit verschiedenen Dekodern).

    Dann mal ein Decode ohne DRC neukomprimieren (mit verschiedenen Enkodern) und ebenfalls wieder mit verschiedenen DRC Einstellungen dekodieren und gucken, wie gut diese den originalen entsprechen.


    Ach ja, wenn man nicht gerade von ac3 in ac3 codiert, fehlt es dem ac3enc zumindest der Möglichkeit die Surrounds mit 90° Phasenverschiebung zu versehen. Properly mastered ac3 sollte dieses haben. Ich kenne zwar den passenden Filter (etwa aus ladspa; Hilbert Filter), doch da das wohl GPL code ist, kann ich den nicht integrieren. Und da ich studiumstechnisch nichts in DSP Richtung gemacht habe, kann ich auch nicht gerade mal so die richtigen Koeff für den passenden FIR Filter berechnen um das gewünschte ohne GPL code zu basteln...(Oder ist es doch LGPL code? Müßte mal da genauer in das plugin nachgucken. LADSPA an sich ist zumidnest LGPL...)

    (Wenn man obiges zuende denkt und berücksichtigt, daß DTS nicht auf downmix ausgelegt ist, so muß man schon ziemlich blöde sein, DTS mal eben so downzumixen ohne einen Hilber Filter vorher anzuwenden (ein kommerzieller Filter sollte aber so schlau sein und das machen; libdts habe ich mir nicht so genau angesehen; kann der downmixen?) und damit die Quali eines DTS downmixes sogar schlechter wird als die eines AC3 Downmixes. Aber es gibt ja genug Spezis, die soweit nicht denken können und unbedingt DTS weiterverarbeiten müssen...)