Cabinet IRs nach Firmware 10 auf dem AxeFx II

[Pacosipulami]

Hallo zusammen

Zugegeben, die Geschichte mit dem neuen IR-Format liess mich gestern nicht mehr los - ich will wirklich wissen was da passiert ist. Also hab ich mir bei Axe-Change zwei User-Cabs des selben Users (CrunchyBob) heruntergeladen und die Files verglichen. Eines vom 8 Mai mit Fw 10, das andere vom 25 Februar - noch mit einer tieferen Firmware erstellt.....

Es hat sich definitiv etwas am Format geändert.....



Alte Wellenform



Neue Wellenform


EDIT: Es ist kein reines PWM-Signal (auf den Pulse ist etwas aufmoduliert!) - es könnte auch eine Mischform von segmentierter und linearer Faltung sein...bin da aber kein Spezialist.

 

[Pacosipulami]

Kann jemand mal ein TMA File unter Fw10 erstellt "anschauen".....ich hab da eine Vermutung, dass dort noch alles "normal" ist, bzw. nichts geändert wurde und nach wie vor in 1024 Auflösung gearbeitet wird.

 

[axefx]

Hier meine kleinen "Forschungsergebnisse": IR old vs. TMA new vs. IR new

Basis war immer die Speaker Simulation meiner Beringer GI100 DI-Box. Diese hatte ich vor FW10 als IR-Capture geschossen und jetzt nochmal mit FW10.05. Diese CAB IR habe ich dann im TMA-Block reproduziert (Synth sine-sweep original=local; sine-sweep durch CAB IR=reference).

Hörergebnis (stark verzerrter Amp Block hinter Synth sine-sweep, zum besseren Unterschiede heraushören können):
1) exportierte IR der getonematchten original IR aus dem TMA Block
2) TMA Block
3) original IR



Fazit: Bis auf die bekannten -3db beim Tonematch bzw. export davon klingt alles, wie es soll. Der Tonematch-Block arbeitet perfekt, IR Export aus TMA Block funktioniert.


Visuelles Ergebniss:
Zu Ansicht eingeladen in Albert A Converter.

"Alte" IR-Capture der Behringer GI100 (VOR FW10)

"Neue" IR-Capture der Behringer GI100 (mit FW10.5)

exportierte IR aus TMA Block, geschossen im LIVE Mode (mit FW10.5)

exportierte IR aus TMA Block, geschossen im OFFLINE Mode (mit FW10.5)

Fazit:
Die Formatierung hat sich definitiv geändert.

Die neue Formatierung wirkt sich auf selbst geschossene IRs mit dem Axe-Fx II IR-capture tool aus und besitzen nach wie vor eine Länge von 2048 (42,5ms).

Die neue Formatierung wirkt sich auch bei exportierten CAB IRs aus dem TMA Block aus, die eine Länge von 1024 (ca. 21ms) im HI RES mode haben, wie bekannt ist. Dabei fällt auch visuell auf, dass es einen (konsequenterweise) Unterschied zwischen Offline- und Live-Mode des TMA Ergebnisses gibt.

Die Möglichkeit selbst erstellte Impulse Responses mit dem Axe-Fx II IR-Capture tool nachträglich in ein .wav Format zu konvertieren, um eigene mit dem Axe-Fx II angefertigte CAB IRs in einer Drittanbieter Umgebung (DAW,etc.) zu nutzen, entfällt also.
Sehr schade! Für den User ein Rückschritt anwendbarer Möglichkeiten.

 

[axefx]

Kann jemand mal ein TMA File unter Fw10 erstellt "anschauen".....ich hab da eine Vermutung, dass dort noch alles "normal" ist, bzw. nichts geändert wurde und nach wie vor in 1024 Auflösung gearbeitet wird.

Kann ich leider nicht, kann nur aus dem TMA eine IR exportieren, wie oben aufgezeigt wirken sich dort die Änderungen in der Formatierung leider auch aus. Aber der Export ist (zumindest für mich) auch die einzige relevante Angelegenheit, um eben eine IR aus dem Axe im PC als .wav zu konvertieren, was jetzt (zumindest mit den mir bekannten tools) nun nicht mehr geht ;(

 

[Jojolamenace]

Könnte das nicht ein little/big endian Problem sein? Irgendwie habe ich das Gefühl, dass das Vorzeichen bei den zwei GI100 plots vor FW10 und mit FW10.5 gleich sind. Cheffe könntest du diese zwei .syx Files zum Download zur Verfügung stellen, damit ich dies analysieren kann? Danke!

 

[Andy]

Könnte das nicht ein little/big endian Problem sein? Irgendwie habe ich das Gefühl, dass das Vorzeichen bei den zwei GI100 plots vor FW10 und mit FW10.5 gleich sind. Cheffe könntest du diese zwei .syx Files zum Download zur Verfügung stellen, damit ich dies analysieren kann? Danke!

Das mit dem großen und dem kleinen Indianer war gestern Abend auch mein erster Gedanke Vielleicht wirklich ein guter Ansatz!

Das PWM Signal, welches man hier sieht passt auch irgendwie überhaupt nicht zu einer Impulsantwort. Zumindest nicht zu einer, bei der sich nach 10 ms so rein gar nichts mehr tut.

Wenn, dann eher zu einer Signalform die evtl. dem Frequenzgang entspricht, also irgendwas wo sich "zum Ende" hin massiv was "tut", also ändert.
Nur macht das dann insgesamt keinen Sinn.

Ich kratz mir momentan auch eher den Kopf und bin noch zu keiner schlüssigen Erklärung oder ner Idee gekommen, außer eben auch ggf. endianess.

 

[axefx]

Cheffe könntest du diese zwei .syx Files zum Download zur Verfügung stellen, damit ich dies analysieren kann? Danke!

Cheffe kann Hier im Zip-file alle 4 CAB IRs aus den obigen Abbildungen. Die, die noch Behringer benannt ist, ist die alte vor FW10, LIVE / OFFLINE der jeweilige TMA CAB IR export des gematchten Cabs, GI100 IR-capture entsprechend mit dem IR tool des Axe erstellt, wie die alte Behringer, nur jetzt neu mit FW 10.05. Klingen sollten die also alle gleich. Bin gespannt, was Du dazu sagst.

https://dl.dropboxusercontent.com/u/47593922/Behringer%20GI100.zip

By the way: Alle Cabs bzw. plots sind AUSSER der ersten Behringer benannten Cab IR mit FW 10.05 erstellt.

 

[Pacosipulami]

Das mit dem großen und dem kleinen Indianer war gestern Abend auch mein erster Gedanke Vielleicht wirklich ein guter Ansatz!

Kannst Du mir das mal bisschen genauer erläutern - klingt spannend. Ich kenne mich diesbezüglich viel zu wenig aus. Will was lernen....

lg
Paco

 

[Pacosipulami]

Ich hab mir erst gedacht, dass da die Möglichkeit offengelassen wurde, zwei Signale in eines zu bekommen, eben um später ggf. die Impedanzkurve in die Impulsantwort einzurechnen.....so eine Art "periodische Faltung"....

Ich bin da nicht so der Hirsch - irgendwie ging das damals alles an mir vorbei und heute bin ich es mir reuig, nie tiefer in die Digitaltechnik abgerauscht zu sein. Kommt mir vor als hätte ich bisschen überall den Anschluss verpasst. Wollte früher immer mitmischeln aber über PSpice hab ich es dann doch nie rausgeschafft - und meine jüngeren Kollegen studieren nun an der TU.....und ich alter Sack (78 Jahrgang) mache noch immer mit Röhren rum....oder flicke MovingHeads.....

Wer hilft einem armen Pacosipulami bisschen auf die Beine?

 

[axefx]

Cliff erklärt, warum das Format geändert wurde:

"The format was changed because in rare cases a sample value would exceed the allowed digital representation. This rarely happens with cabs but if you do IRs of preamps or other less conventional things this can happen. The new format doesn't suffer from this problem."
Quelle: http://forum.fractalaudio.com/axe-fx-ii-user-cabs-irs/69120-new-format-irs-fw-10-a.html#post850355

Das ganze hat also eine technische Erklärung.

 

[Jojolamenace]

Danke für die .syx Files. Ich habe die Kurven verglichen und festgestellt, dass das Signal im neuen Format logarithmisch komprimiert wird. Der positive Anteil des Signals befindet sich zwischen (0,1], der negative Anteil bei [-1,0) (der neg. Anteil muss natürlich zuerst in ein pos.- Signal umgewandelt werden, wahrscheinlich die abs() Fkt.) und 0 bleibt 0 da Log(0) = -Inf. Ich habe mit einer Optimierung versucht das neue Format (FW10.5) zu Rekonstruieren (nur positiver Anteil). Dabei habe ich folgende Transformtion verwendet:

X_real = 10^((X_FW10 - A)*D)/10^D*C-B (gilt nur für den pos. Anteil des Signals)

mit A=-0.9211, B=9.9920e-006, C=1.8161e-033, D=46.0261 (mit Optimierung ermittelt)
X_real: das "echte" (vor FW10) Signal, X_FW10 das Signal im FW10 Format

Anbei noch eine kleine Illustration

Ganzes Signal:

Zoom 1:

Zoom 2:



Meine Transformation ist sicher nicht korrekt. Aber es zeigt, dass der Log.-Ansatz wahrscheinlich richtig ist. Das macht auch Sinn, wenn das Ziel des neuen Formats ist, eine Überschreitung des digitalen Bereiches zu verhindern (gemäss Fractal). Ich hoffe, dass der korrekte Algorithmus auch veröffentlicht wird.


PS: Was bedeutet Cheffe eigentlich? "Chef" mit italienischem Akzent?

 

[axefx]

Zur Info:

Yes, the previous format is also supported.

FWIW, one of my fundamental tenets of this company is "never makes decisions based on greed". IOW, don't pull an Adobe. The decision to change the format was purely technical. The data is not encrypted (like other products), it's just in a different format.

Paco und ich haben darauf mal auf Deine Analyse verlinkt: http://forum.fractalaudio.com/axe-fx-ii-user-cabs-irs/69120-new-format-irs-fw-10-a-2.html#post850601

Ich hoffe und bin guter Dinge, das sich jemand findet, welcher der Gemeinde wieder einen .wav Converter für das FAS IR Format zaubern kann ... auch dank Deiner Analyse, danke dafür!

 

[Andy]

Kannst Du mir das mal bisschen genauer erläutern - klingt spannend. Ich kenne mich diesbezüglich viel zu wenig aus. Will was lernen....
lg
Paco

Hallo Paco, das mit der endianess hat letztendlich damit zu tun, wie man Datentypen, die größer als ein Byte sind im Speicher ablegt.
Wenn ein Byte mit seinen 8-Bit und einem Wertebereich von 0 bis 255 nicht mehr ausreicht und man
bspw. einen 16-Bit Wert verwendet (Wertebereich von 0 bis 65535 als unsigned int, also vorzeichenloser integer-Wert)
der Speicher aber byteweise organisiert ist, also jedes Byte eine eigene Adresse hat,
hat man nun grundsätzlich zwei Möglichkeiten die beiden Bytes "von der Reihenfolge" her im Speicher
abzulegen.

Entweder das Byte mit den höherwertigen Bits auf die niedrigere Adresse (big endian)
oder das Byte mit den niederwertigsten Bits auf die niederigere Adresse (little endian).

Beispielsweise:

Wert 20.000 => binäre Darstellung 01001110 0010 0000

oberes Byte: 0100 1110 unteres Byte: 0010 0000 => hexadezimale Darstellung 4E 20

Das "obere Byte" wäre demnach das mit den 4E und das "untere Byte" das mit der 20 in hex. Darstellung.
Bei big endian legt man die 4E auf bspw. die Adresse 1000 und die 20 dann auf die Adresse 1001.
Bei little endian läge die 20 auf Adresse 1000 und die 4E auf Adresse 1001.

Big endian:

Adresse - Wert
1000 4E
1001 20

Little endian:

Adresse - Wert
1000 20
1001 4E



Solange man bei der gewählten "endianess" beim Speichern und Auslesen bleibt ist alles ok.
Bei einem angebundenen Speicher ändert sich dies ja auch nicht.

Das gilt jetzt aber auch (oder kann) für die Ablage der Werte in Dateien gelten.
Da besteht jetzt aber schon die Möglichkeit anders auszulesen als zu schreiben.
Wechselt man, d.h. man schreibt im Modus little endian in eine Datei und liest sie aber als big endian aus oder anders herum,
dann drehen die Bytes ihre Reihenfolge, d.h. aus

4E 20 wird dann 20 4E was nicht mehr der 20.000 dezimal entspricht, sondern 8270.

Ist hier noch etwas anschaulicher beschrieben:
http://de.wikipedia.org/wiki/Byte-Reihenfolge

Motorola verwenden klassisch big endian, während Intel little endian verwendet.

Der Verdacht war nun, dass bei den Syx. genau so etwas passiert hat sich aber nun nicht bestätigt.

@ Jojolamenance: Super Arbeit!

 

[Pacosipulami]

Danke Andy

Hab gerade Lust auf meine alten Theoriebücher bekommen.....Sonntags-Lektüre! Schön Dich hier im Forum zu wissen!

 

[Jojolamenace]

Ich hoffe und bin guter Dinge, das sich jemand findet, welcher der Gemeinde wieder einen .wav Converter für das FAS IR Format zaubern kann ... auch dank Deiner Analyse, danke dafür!

Ich glaube ich habe es geschafft. Der Unterschied zwischen altem und neuem Format ist folgender:
alt: 32bit integer fixed-point
neu: 32bit floating point --> das erklärt auch die logarithmische Kompression

Leider habe ich den Code zum Analysieren und zum Konvertieren bis jetzt nur in Matlab oder Octave.

 

[axefx]

Ich glaube ich habe es geschafft. Der Unterschied zwischen altem und neuem Format ist folgender:
alt: 32bit integer fixed-point
neu: 32bit floating point --> das erklärt auch die logarithmische Kompression

Leider habe ich den Code zum Analysieren und zum Konvertieren bis jetzt nur in Matlab oder Octave.

Das wäre ja der Hammer! Schreib doch Cliff nen Zweizeiler und frage ihn, ob das stimmt. Wenn es stimmt, kann ich mir gut vorstellen, dass er bestätigt.

Aber lass mich raten: Das ganze jetzt in ein ausführbares Java-Programm oder ähnliches zu überführen - das ist nen Haufen Arbeit. Was wäre, wennDu Dich mit Albert zusammentust und ihr bohrt seinen alten Albert`s A Converter einfach auf? Den Kerle findest Du hier: http://forum.fractalaudio.com/members/alberta.html . Das war der Pionier auf dem Gebiet seit 2008

Gute Arbeit Jojo! Respekt

 

[Andy]

@Paco, jetzt erst gesehen. Danke für die Blumen

@Jojolamenace: soweit ich die Impulse Responses sehe sind die doch eigentlich normiert, d.h. die gehen nur von -1 bis +1.
Hab mir aber jetzt auch nicht so viele IRs angesehen.

Ich hätte jetzt fast erwartet, dass die Jungs den Datentyp "fractional" verwenden.

Hab momentan viel zu tun, insofern kann ich da grad nicht wirklich aktiv mitarbeiten. Ich versteh aber auch die Logik hinter dem Syx Format nicht so wirklich.
Insofern weiß nicht nicht, wo da die eigentlichen "Daten" sind.

Hier mal ein kurzer Exkurs zum Fractional Datentyp, vielleicht hilft es weiter (sofern der nicht eh schon bekannt ist):
http://mit.eit.h-da.de/Vorlesung/1300_MathematischeOperationen.pdf

Gruß

Andy

 

[Jojolamenace]

1) @Jojolamenace: soweit ich die Impulse Responses sehe sind die doch eigentlich normiert, d.h. die gehen nur von -1 bis +1.
Hab mir aber jetzt auch nicht so viele IRs angesehen.

Ich hätte jetzt fast erwartet, dass die Jungs den Datentyp "fractional" verwenden.

2) Hab momentan viel zu tun, insofern kann ich da grad nicht wirklich aktiv mitarbeiten. Ich versteh aber auch die Logik hinter dem Syx Format nicht so wirklich.
Insofern weiß nicht nicht, wo da die eigentlichen "Daten" sind.

3) Hier mal ein kurzer Exkurs zum Fractional Datentyp, vielleicht hilft es weiter (sofern der nicht eh schon bekannt ist):
http://mit.eit.h-da.de/Vorlesung/1300_MathematischeOperationen.pdf

Gruß

Andy

1) Ich habe bis jetzt auch nur IR Cabs im Interval [-1,1] gesehen. Theoretisch kann anscheinend das Signal auch grösser 1 werden. Bei fixed-point wird alles über 1 abgeschnitten. Deshalb hat Fractal neu das Format floating point gewählt.

2) Das mit dem .syx Format war bis gestern auch mein Problem. Ich habe für die Umwandlung von .syx zu .wav den "axeomatic.exe" (http://www.ownhammer.com/free/axe-o-matic/) verwendet. Leider wandelt diese Ding das Signal nur in 24bits um. Deshalb habe ich gedacht, dass die Daten im .syx auch nur 24bits haben. Da ich bis gestern keinen Konversion-Algorithmus finden konnte, habe ich mir das .syx Format leider auch anschauen müssen (zum Glück gibt es bereits eine Beschreibung im Fractal-Wiki dazu, http://wiki.fractalaudio.com/axefx2/index.php?title=MIDI_SysEx#Axe_Fx_II_SysEx_Information_for_loading_IRs), mit der Hoffnung noch versteckte Bits zu finden. Tatsächlich habe ich dann noch 8 Bits gefunden.

3) Ich habe bereits alles in Matlab implementiert. Dabei habe ich das Format "Single-precision floating-point format" gemäss IEEE 754 gewählt. (https://en.wikipedia.org/wiki/Single_precision)

Natürlich habe ich meine Konversion auch überprüft. Dazu habe ich in meiner DAW eine Audiospur mit einem Impulssignal kreiert. Impulssignal bedeutet ein Signal mit einem Sample auf max. Amplitude und alle folgenden Samples auf 0. Dieses Signal habe ich über USB in den Axe-FxII eingespeist und das FxII-Ausgangssignal (Antwort) in der DAW aufgenommen. Das FXII Preset besteht natürlich nur aus der CAB. Das aufgenommene Signal ist dann die Impulseantwort (weil der Input ein Impuls ist). Wenn man keinen Converter hat, kann man auch auf diese Weise das .syx File in ein .wav File umwandeln.
Anbei ein Bild vom Impuls (grün) und die Impulsantwort (gelb). Zwischen dem Impuls und der Impulsantwort (IR) hat es auch eine Totzeit (Verzögerung). Das ist die Latenz des Axe-FX!! (aber keine Panik: das sind nur ca. 0.6ms)


Anbei den Vergleich zwischen dem konvertierten .syx Signal und der DAW-Impulsantwort.

Wie man sehen kann, gibt es noch ein Problem mit der Amplitude (Gain). Der Unterschied ist ziemlich genau sqrt(2). Wahrscheinlich hat es irgendwo in meiner DAW oder im Axe-FXII ein Gainregler, der auf -3dB steht.
Den Gain kann ich noch normalisieren (nur die DAW-Impulsantwort wird mit einem Faktor (ca. -3dB) korrigiert). Die Normalisierung habe ich mit dem Sample mit max. Amplitude (siehe roter Pfeil) vorgenommen.

Ich behaupte mal, dass das Format "Single-precision floating-point format" gemäss IEEE 754 ziemlich gut funktioniert.

Und noch den Matlab-Code:

clear all

% Load DAW Impulse Response
if 1
[y1, fs1, nbits1] = wavread('IR_Cab.wav');
y1 = double(y1,1));
ind1 = find(y1>0);
y1(1:ind1(1)-1) = [];
y1(2041:end) = [];
t = 0:1/fs1:2039/fs1;
end

% Read .syx File
filename = 'GI100 IR-CAPTURE FW10.syx';

fid = fopen(filename,'r');
A = fread(fid,10904,'uchar');
fclose(fid);

A = dec2hex(A);
ind_data = strmatch('F0',A);
ind_data([1 end]) = [];
IR_data = A(ind_data(1)+8+[0:159],;
IR_name = IR_data(1:40,;
IR_data(1:40, = [];
for n = 2:length(ind_data)
IR_data = [IR_data; A(ind_data+8+[0:159],];
end

s = reshape(IR_data',10,prod(size(IR_data))/10)';
s = s,[9 10 7 8 5 6 3 4 1 2]);

b = dec2bin(hex2dec(s));
b = ['0'*ones(size(s,1),40-size(b,2)) b];
b,(0:4)*8+1) = [];

c = dec2hex(bin2dec(b));
num = zeros(size(c,1),1);
ind_pos = c,1)=='0';
num(ind_pos) = hex2dec(c(ind_pos,2:end));
ind_neg = c,1)~='0';
num(ind_neg) = -bitcmp(hex2dec(c(ind_neg,2:end)),32)+1;


% Convert into Floating point 32bits
y2 = num);

y2 = double(y2);
ind_neg2 = find(y2<0);
y2(ind_neg2) = bitcmp(abs(y2(ind_neg2)),32) + 1 ;

% Floating point 32bits
S = bitget(y2,32);
E = bitand(y2,hex2dec('7F800000'))/2^23;
M = bitand(y2,hex2dec('007FFFFF'));
num = (-1).^S .* 2.^(E-127) .* (1 + M/2^23);

% Plot results
figure(1)
set(gcf,'color',[1 1 1])
plot(t,num,'-x',t,y1/max(y1)*max(num),'-o','LineWidth',2,'MarkerSize',10)
grid on

figure(2)
set(gcf,'color',[1 1 1])
plot(t,num,'-x',t,y1,'-o','LineWidth',2,'MarkerSize',10)
grid on
xlim([0 1e-3])
ylabel('amplitude [-]','FontSize',14)
xlabel('time ','FontSize',14)
set(gca,'FontSize',14)
legend('IR CAB .syx conversion','DAW Impulse Response')
title('Conversion of the IR Cab .syx')

figure(3)
set(gcf,'color',[1 1 1])
plot(t,num,'-x',t,y1/max(y1)*max(num),'-o','LineWidth',2,'MarkerSize',10)
grid on
xlim([0 1e-3])
ylabel('amplitude [-]','FontSize',14)
xlabel('time ','FontSize',14)
set(gca,'FontSize',14)
legend('IR CAB .syx conversion','DAW Impulse Response')
title('Conversion of the IR Cab .syx')

 

[axefx]

Ich staune! die -3db könnten vom Axe her rühren. Zumindest sind auch TMA -> Cab Exporte -3db leiser, ich weiss nicht mehr genau, warum, Headroom-Schutz oder sowas? Ist jetzt auch was anderes, aber als ich -3db gelesen habe ... das kam mir irgendwoher bekannt vor

Du scheinst dem ganzen ziemlich dicht auf den Fersen zu sein. Jetzt müssen wir also nur noch jemanden finden, der das ganze in ein Java-Programm oder ähnliches schreiben kann?

Jedenfalls: Krasse Studien! Da Capo!

 

[Jojolamenace]

Ich staune! die -3db könnten vom Axe her rühren. Zumindest sind auch TMA -> Cab Exporte -3db leiser, ich weiss nicht mehr genau, warum, Headroom-Schutz oder sowas? Ist jetzt auch was anderes, aber als ich -3db gelesen habe ... das kam mir irgendwoher bekannt vor

Du scheinst dem ganzen ziemlich dicht auf den Fersen zu sein. Jetzt müssen wir also nur noch jemanden finden, der das ganze in ein Java-Programm oder ähnliches schreiben kann?

Jedenfalls: Krasse Studien! Da Capo!

Vielen Dank für die -3dB Bemerkung. Somit ist eigentlich alles klar; abgesehen von der User-Friendly-Software in Java, C, oder was auch immer.

Das einfachste wäre, wie du bereits oben geschrieben hast, den Albert zu kontaktieren. Wenn der Albert mitmacht, müssten wir nur 4 Matlab-Zeilen in Java umschreiben. Bevor ich ihn kontaktiere, möchte ich aber zuerst sein Converter-Tool sehen (damit ich mit ihm auch ein bisschen fachsimpeln kann). Ich habe keine Ahnung wie das Ding aussieht (hat es z.Bsp. eine Graphic User Interface, wird eine 24Bit oder 32Bit .wav Datei erstellt, usw. ?). In den Foren wird es viel zitiert, aber ich habe es im Internet nie gefunden (darum verwende ich den "axeomatic.exe" (http://www.ownhammer.com/free/axe-o-matic/)). Kann man das irgendwo auch downloaden?