neues Spielzeug

[Pacemaker]

Schlecht wäre die Idee nicht, aber die ist wohl noch buggy (hab ich gehört)

[LigH]

Wenn ich recht informiert bin, dann müssen Programme, die nur eine GPL-DLL benutzen, nicht komplett ebenfalls unter GPL laufen - das gelte lediglich für die DLL, die eine GPL-Bibliothek implementiert. Oder?!
__

@ Pacemaker: Darum geht es doch gerade. Wenn da noch Fehler drin wären, dann müsste DarkAvenger unbedingt konkret wissen welche - "hab mal gelesen" ist da überhaupt nicht hilfreich, besonders wenn sich dieses Gerücht vielleicht noch auf Versionen von vor einem Jahr beziehen sollten.

[Pacemaker]

@ Ligh

Dies hatte ich auf der Page vom VLC gelesen http://www.videolan.org/dtsdec.html
Viel steht da nun auch nicht

[DarkAvenger]

@Ligh

Nö so einfach ist das nciht. Sonst könnte man ja für jedes GPL Programm eine LGPL wrapper dll machen und diese dann in einem closed source Programm nutzen. Das ist nicht im Sinne des Erfinders.

[hans-jürgen]

Naja, wie schon gesagt, Nero plugin interface kommt nicht in Frage, aber werde mir faac nochmal angucken. Evtl habe ich (oder die) bei deren dll Verson Murks gamcht. Mal gucken...

Ach so, Du hast die DLL-Version benutzt... Um die hat sich kaum jemand gekümmert in letzter Zeit, weil libfaac.dll das Output-Plugin für WinLAME und CDex ist. Inwieweit sich dort also ein Bug versteckt, der bei der Kommandozeilenversion nicht vorkommt, kann ich Dir leider nicht sagen. Nur so viel, daß auf meinem Win95 libfaac.dll in CDex mit einem Windows-Error bzgl. der "MSVCRT.DLL" abstürzt. Ob das bei anderen Usern auch so ist, versuche ich gerade im CDex-Forum herauszufinden. Allerdings hat der BonkEnc-Entwickler (noch ein Open Source CD-Ripper) auch diese Version als Grundlage für sein Plugin genommen und keine Schwierigkeiten gehabt.

Es gibt außer diesem Output-Plugin übrigens noch weitere FAAC-Implementationen im SourceForge-CVS, z.B. für Winamp und CoolEdit, die gerade frisch überholt worden sind. Deren Entwickler meinte neulich mal, daß er sie so angelegt hat, daß eine Abwandlung für andere Anwendungen ziemlich leicht sei.

[DarkAvenger]

Gute Nachrichten, das mit faac wird wohl klappen, könnte nur noch an meinem Unvermögen scheitern. Habe extra mal Windows hochgefahren weil ich neugierig war und die dll verhält sich so, wie man es erwarte, *wenn* man sie richtig initialisiert. Das erklärt auch, warum bei der letzten alpha der encoding Vorgang am Schleichen war....aber könnte auch an der Komplexität von dem Profil liegen...

Kann mir mal jemand das channel mapping erklären?

 	Channel Remapping
 
 		Default    		0, 1, 2, 3 ... 63  (64 is MAX_CHANNELS in coder.h)
 
 		WAVE 4.0		2, 0, 1, 3
 		WAVE 5.0		2, 0, 1, 3, 4
 		WAVE 5.1		2, 0, 1, 4, 5, 3
 		AIFF 5.1		2, 0, 3, 1, 4, 5

Welche Zahl steht für welchen Kanal? Scheint aber wohl abhänig von der # der Kanäle zu sein...grrrr

[hans-jürgen]

Gute Nachrichten, das mit faac wird wohl klappen, könnte nur noch an meinem Unvermögen scheitern.

Sehr schön, danke...

Habe extra mal Windows hochgefahren weil ich neugierig war und die dll verhält sich so, wie man es erwarte, *wenn* man sie richtig initialisiert. Das erklärt auch, warum bei der letzten alpha der encoding Vorgang am Schleichen war....aber könnte auch an der Komplexität von dem Profil liegen...

Aha, dann kann es sein, daß Du ausgerechnet das LTP-Profil als Default eingestellt hattest, denn das ist leider noch buggy = ca. 50x langsamer als LC. Main ist nur ein bißchen langsamer als LC, aber derzeit auch nicht zu empfehlen, da es noch nicht genügend getunt ist (produziert leichte Artefakte).

Kann mir mal jemand das channel mapping erklären?

	Channel Remapping
 
		Default 		0, 1, 2, 3 ... 63 (64 is MAX_CHANNELS in coder.h)
 
		WAVE 4.0		2, 0, 1, 3
		WAVE 5.0		2, 0, 1, 3, 4
		WAVE 5.1		2, 0, 1, 4, 5, 3
		AIFF 5.1		2, 0, 3, 1, 4, 5

Welche Zahl steht für welchen Kanal? Scheint aber wohl abhänig von der # der Kanäle zu sein...grrrr

Das bezieht sich eigentlich auf das interne AAC-Channelmapping, wo Centre = 0 (also der erste) ist und LFE = 5 bzw. der letzte bei mehr als 6 Kanälen, 1 und 2 also FL und FR sowie 3 und 4 SL und SR. Nur wie sich dann z.B. WAVE 5.1 erklären soll, weiß ich auch nicht... Hast Du das aus FAAC oder aus FAAD2 (wo sich dann ja im Ausgang das 5.1 WAVE-Mapping FL, FR, C, LFE, SL, SR ergeben soll). Es kann aber auch sein, daß das nur ein zukünftiges, d.h. unbenutztes und deaktiviertes Mapping ist, das schon mal angedacht und implementiert wurde, um alle möglichen Layouts im Frontend abdecken zu können. Im Moment kann man nämlich mit dem -I Parameter nur definieren, wo sich Centre und LFE in der Input-Datei oder -Bitstream befinden (Default ist 3,4). Ich werde mal die Mailingliste durchforsten, ob ich noch ein paar Mails zum Thema finde.

[hans-jürgen]

OK, war nicht in der Mailingliste, sondern im Webforum:

http://www.audiocoding.com/phorum/re...&i=4109&t=4027

Das ist also eine alternative Methode fürs Remapping, die von Stux (= Stuart Espey, 3ivx-Entwickler) eingebaut wurde, um eben alle denkbaren und undenkbaren (z.B. AIFF) Channel-Layouts in der Input-Datei zu bedienen. Übrigens benutzt 3ivx für seinen DS Audio-Encoder auch libfaac.

[DarkAvenger]

Danke, ich werde es mir mal angucken.

[DarkAvenger]

So, habe mal basic AAC support reingebaut, der auch dieses Mal funktionierende Dateien porduziert. Noch kann man nichts einstellen.

Ich bitte folg zu überprüfen: Tendiert der output zum clipping? (Läßt es sich vermeiden?) Ich weiß nciht, ob es am encoder/decoder/player oder an hac3 liegt.

Was ist am ch mapping falsch? Ich hatte noch keine Zeit mir obiges richtig durchzulesen. Am einfachsten wäre es, wenn jemand mal probiert 6Kanal Zeugs oder so zu füttern und mir dann sagt, ob es geht und dann, was flasch ist...