neues Spielzeug

Dankeschön für diese Testversion, ich habe auf Audiocoding.com, Everwicked.com und Doom9.org auch darauf hingewiesen - hoffentlich hast Du nichts dagegen...

Der erste Schnelltest mit einer simplen Stereo-WAV-Datei funktionierte fast perfekt, am Ende hängt komischerweise wohl noch ein wiederholtes Sample aus der Mitte der Datei dran, was mit faac.exe nicht passiert. Ist die libfaac.dll jetzt original aus dem CVS, oder hast Du noch etwas daran geändert (von wegen "richtig initialisiert")?

Die 20sec-Datei hört sich nicht übersteuert an, allerdings habe ich auch nicht mit den Normalize- oder Global Gain-Reglern rumgespielt. Bei den noch deaktivierten FAAC-Optionen gibt es ein Bitraten-Setting von "mind. x kbps", was bedeutet das? Ebenso ist mir 2-pass noch nicht ganz klar (generell schon, aber FAAC kann das eigentlich nicht)? Beziehst Du das einfach auf die temporäre WAV-Datei, die zwischendurch erzeugt wird, oder auf die exakte Größenbestimmung fürs CD-Brennen, benutzt HeadAC3he also immer den ABR- und nie den VBR-Modus?

Mehrkanaltests werde ich heute mal machen (mit einer Speaker-Testdatei in AC3), kann aber mangels Surround-Soundkarte nicht direkt sagen, ob beim Channelmapping etwas schiefgeht...

2Pass ist nur zur Normalisierung.

Ach so, alles klar... Ansonsten kann ich von meinem ersten geglückten Transcoding-Versuch mit der 5.1 AC3-Datei berichten, allerdings sind tatsächlich FL und Centre in der AAC-Datei vertauscht (vielleicht aber auch durch die azid.dll verursacht?). Ansonsten stimmen die Kanäle, soweit ich das im Stereo-Downmix von foobar2000 beurteilen kann, denn ich glaube nicht, daß Front und Rear komplett vertauscht sind. Bei dieser kurzen Datei kann ich auch keinen "Rest-Frame" am Ende hören, aber das wäre womöglich auch schwierig, weil da eh nur LFE-"Muh-muh" ist.

Zitat von DarkAvenger

Ok, danke erst mal für die Analyse. Kannst du um das mit dem ch mapping zu überprüfen, in fb2k das aac in ein 6ch wav dekodiern und das mal im Editor überprüfen? Owbohl, birngt ja eigentich auch nciht viel. Hmmm.

Daß FL und C vertauscht sind (auch in Mpxplay übrigens, nicht nur in foobar2000), ist sicher, d.h. der Ansager fängt an mit "Front Left", was aus der Mitte kommt, dann sachter "Centre" aus dem linken Lautsprecher. Das interne AAC-Channelmapping lautet wie gesagt C, FL, FR, RL, RR, LFE, also zuerst ein single_channel_element (SCE), dann alle channel_pair_elements (CPE), am Schluß wieder ein single_channel_element für den LFE.

Zitat

Das mti dem sample am Ende müßte ich mal analysieren. Dürfte eigentlich nciht von hac3 erzeugt werden, aber wer weiß...mit anderen formaten passiert das nciht (ac3)?

Leider habe ich keine AC3-Encoder-DLL auf Deiner Homepage gefunden und deshalb die für LAME heruntergeladen, aber die bricht mit einem Windows-Error ab, so daß ich nicht weiß, ob sie auch am Schluß etwas dranhängen würde. Jedenfalls ist das mit libfaac.dll reproduzierbar, wenn ich meine Test-WAV benutze: http://home.arcor.de/hans-juergen.b…t_reference.exe (ein SFX-RAR Archiv).

Zitat

Geändert habe ich an libfaac nur zwei dinge: 1) float input wird mit 32k multipliziert 2) Was mich zimelich viel ZEti gekostet hat um es heirauf zurückzuführen: Ein _declspace(dllexport) (oder so ähnl) an die exportierten Funkt drangehangen, sonst hatte ich es nciht geschaft die dll dyn zu laden. Ansonsten ist die dll unverändert.

Könntest Du davon ein Patch zur Verfügung stellen und es z.B. in die faac-dev Mailingliste posten oder im Bugtracker von SourceForge (akzeptiert Dateianhänge), so daß ein Entwickler die Änderungen ins CVS einfügen kann? Sind sie generell nötig, oder nur speziell für HeadAC3he? Ich frage, weil ich bisher mit libfaac.dll auf meinem Uralt-System kein Glück hatte und angenehm überrascht war, daß es jetzt klappt.

@ hans-jürgen:

Die auf HeadAC3he angepasste AC3ENC.DLL liegt im Archiv von HeadAC3he 0.24a9 (siehe Anfang dieses Threads) mit bei.

Zitat von LigH

Die auf HeadAC3he angepasste AC3ENC.DLL liegt im Archiv von HeadAC3he 0.24a9 (siehe Anfang dieses Threads) mit bei.

Stimmt, hatte ich schon vergessen... dort wird auch ein generelles Memoryleak erwähnt, wahrscheinlich will deshalb bei mir die lame.dll nicht. Dann werde ich mal gleich mit AC3 testen.

Zitat von DarkAvenger

Ich werde mir mal deine wav angucken. Das mit dem ch mapping scheint ja dann einfach zu fixen sein. Muß nur im mapping ch0 und ch1 vertauschen.

Ja, Centre ist 0, stand auch in diesem Thread bei Audiocoding.com drin. Übrigens ist diese WAV-Datei in Stereo, für den Multichannel-Test habe ich eine AC3-Datei benutzt.

Zitat

Mit dem patch wird das etwas blöd, weil in der aktuellen Form zu "breaking things" führt. Dann müßte ich ein neues input format definieren und mit den dll spez. Aufrufparametern(?) müßte ich experimentieren, da ich da keine große Ahnung auf dem Gebiet habe.

Was die verschiedenen Parameter angeht, kann ich Dir wahrscheinlich weiterhelfen. Übrigens ist die normale libfaac.dll in CDex auch falsch konfiguriert, was die Defaults angeht (benutzt Main statt LC etc.). Die normalen Standardvorgaben sind: MPEG-2 AAC Datei mit LC-Profil, VBR-Quality 100%, Cutoff bei 16 kHz, M/S-Matrixing und TNS an. Für Video-Transcodings bietet sich das MP4-Format an, das man entweder mit -w oder -o *.mp4 auf der Kommandozeile aktivieren kann. Das ist aber bei der libfaac.dll noch nicht integriert (nur bei foo_faac, out_aac und cool_faac), weil man dazu auch Teile der libmp4v2 aus dem FAAD2-Sourcecode braucht.

Außerdem benötigt man für Videos nur eine niedrigere VBR-Qualität von 75%, wodurch seit v1.24 automatisch der Cutoff auf 13 kHz gesetzt wird. Die durchschnittliche Bitrate sollte dann am Ende ca. 230 kbps/6ch für AAC/MP4 betragen bei einer AC3-Quelle mit 448 kbps/6ch.

Zitat

Aber das hier könnte (weiß ich halt nicht genau) generell nötig sein, wenn man libfaac.dll nur dynamisch laden möchte. Statisch verlinken klappt mit der originalen, aber finde ich wenig attraktiv

Wie auch immer, Deine libfaac.dll läuft hier mit HeadAC3he (aber nicht mit CDex), während die normale von RareWares oder Case weder mit CDex noch HeadAC3he auf meinem Win95-System funktioniert. Deshalb sind Deine Änderungen wichtig und interessant für eine mögliche Weiterentwicklung, und Du solltest sie irgendwo "hinterlassen", damit man sie angucken kann. :)<!-- / message --><!-- sig -->

Die FAAD.EXE kann HE-AAC decodieren, soweit ich das bei http://www.rarewares.org gelesen habe. Ob's die Library auch tun würde, bleibt zu testen - aber warum nicht? Die AAC-Lizenzen kenne ich nicht auswendig, aber mit Decodern haben manche Hersteller weniger Probleme gemacht als mit Encodern.

Zitat

Klappt die lame.dll von meiner Seite? Habe lange nicht mehr mp3 probiert. Das memleak dürfte eigentlich nichts damit zu tun haben. (Aber wer weiß...evtl hast du ja einen wertvollen Tip gegeben zum Fixen des leaks.)

Hier ist die reproduzierbare Fehlermeldung mit Deiner Lame.dll, wenn ich die WAV-Datei ohne Änderungen in den Einstellungen kodieren will:

----
HEADAC3HE führte eine ungültige Anweisung in
Modul LAME_ENC.DLL bei 0137:00bda1fd aus.
Register:
EAX=00d44240 CS=0137 EIP=00bda1fd EFLGS=00010246
EBX=0099dbb0 SS=013f ESP=0098d910 EBP=00000000
ECX=00d44240 DS=013f ESI=00000000 FS=2d97
EDX=00d44250 ES=013f EDI=00000000 GS=0000
Bytes bei CS:EIP:
0f ef c0 0f 7f 84 07 96 8b 02 00 0f 77 c7 84 07
Stapelwerte:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
----

Und hier der Ausschnitt aus der Log-Datei:

----
Starting Process...
Setting up Lame ...succeeded
Allocating buffer memory ...succeeded
Starting I/O thread ...done
WAVE converting cycle ...done
WAVE converting cycle ...done
Closing I/O thread ...done
Freeing buffer memory ...done
Pass 2:
Allocating buffer memory ...succeeded
Starting I/O thread ...done
WAVE converting cycle ...done
MP3 encoding cycle
----

Zitat

Bzgl faad2: Stimmt es, daß dieses GPL ist? Also nix mit HE-AAC dekodieren... Was macht fb2k? Kann es HE-AAC dekodieren? Dann dürfte es ja nciht faad2 benützen.

Ja, FAAD2 ist GPL, während der veraltete Decoder FAAD LGPL ist, der aber noch geändert werden darf, wie mir Menno gerade gestern bestätigte. Allerdings schätze ich mal, daß der HE AAC-Code nicht dazu gehören würde... Foobar hat eine "Sondergenehmigung" von Nero, soweit ich weiß. Aber das Winamp-Plugin in_mp4.dll ist ja nach wie vor frei verfügbar, so daß man dafür ein Interface in einen Player einbauen könnte, wenn man damit HE AAC dekodieren will.

Zu HeadAC3he: Ich habe vorhin die WAV-Datei mit der neuen AC3.dll getestet, und die produzierte 448 kbps/stereo Datei hat keine hörbaren Reste am Ende. Woher also dieser Rest mit libfaac.dll kommt, weiß ich leider auch nicht. Er ist wie gesagt sehr kurz (weniger als 1 Sekunde) und scheint ungefähr aus der Mitte der WAV-Datei zu stammen.

448 kbps / stereo? :eek: Macht das Sinn?
__

Solche übrigbleibenden Reste sind teilweise leicht erklärbar (siehe Anfangs-Knackser beim MP2-Transcoding mit BeSweet) - aber ausgerechnet aus der Mitte, da kann man sich ja nun gar keinen Zusammenhang vorstellen...

Zitat

<!-- / message -->Könnte jemand probieren mit faad1 ein he-aac zu dekodieren? Um was mit interessieren würde, welchen aac Dekoder fb2k benutzt. (Wenn Nero plugin, ist es wieder uninteressant...)

FAAD1 würde den SBR-Teil ignorieren und somit nur den AAC LC-Teil bis ca. 10 kHz wiedergeben, genauso wie QuickTime bzw. iTunes, mpegable/compaact! oder das originale Nullsoft-Plugin für Winamp.

Früher hat foobar eine eigene foo_mp4.dll zur Wiedergabe benutzt, aber seit einigen Wochen ist das ins Standard-Input-Modul gewandert, und foo_mp4.dll wird nicht mehr benötigt.

Übrigens bietet RealNetworks in ihrem Open Source-Projekt Helix sogar einen HE AAC-Encoder als SDK von Coding Technologies an, wenn man sich dort registriert (die Auflagen kenne ich aber nicht). Also schätze ich mal, daß es dort auch irgendwo einen HE AAC-Decoder außerhalb vom neuen RealPlayer 10 Gold geben muß.<!-- / message -->

Zitat von LigH

448 kbps / stereo? :eek: Macht das Sinn?

Logo, ist immer noch weniger als APE - und beinahe transparent...

Zitat von DarkAvenger

Hmmm, wenn es aus der Mitte stammt, könnte es doch ein Problem in HAC3 sein...wenn der SPeicher ausreicht, kann HAC3 in 2 Schritten die Kodierung durchführen. zumindest weißt das auf den Fhelr. Verstehen tue ich aber nciht, daß es nur bei faac auftritt...

Genügend freier Speicherplatz auf der Festplatte ist für diese kurze Datei (WAV 3,5 MB) vorhanden, und Arbeitsspeicher auch (48 MB), weil ich neben HeadAC3he keine anderen Programme laufen lasse.

Zitat

lame: Ach die libmmd.dll hast du aber auch gezogen?

Ja, ist da (von 2002), weil ich sie mal für irgendwas brauchte, Speek's "Ivan & Menno", glaube ich...
<!-- / message -->

Zitat

Um für den zweiten Teil zu kodieren, schriebt es den Rest in einen temporären Puffer, der zu kurz für einen witern VOrgang war. Verstehen tue ich aber nciht, daß es nur bei faac auftritt...zumal ich nciht wüßte, warum er gegen Ende den temp. Puffer anrühren sollte...

Bei den "2-pass, dumb" usw. Einstellungen kann man ja libfaac nicht fürs direkte Piping auswählen, obwohl der Codec das könnte. Ist es bei AC3 nicht anders, wird dort also der stdin benutzt? Jedenfalls glaube ich, daß das bei meinem Test so voreingestellt war...

Ich dachte zuerst, AC3 würde bei 2-pass den "hybrid" mode wählen, habe mich aber getäuscht, weil der nur solange aktiviert ist, wie man noch keine Input-Datei gewählt hat, dann wechselt er für AC3, AAC und alle anderen ja automatisch auf "dumb".

Ich bin jetzt zwei Tage weg, kann also erst mal nicht weiter testen. Vielleicht springt ja mal jemand anderes ein (über 1000 views für diesen Thread)...