Software Mummert-Dissertation (SWMUMDIS)
Mit diesem Programmsystem werden Verfahren zur gehörorientierten Zeit-Frequenz-Repräsentation von Audiosignalen bereitgestellt, die in der Dissertation Mummert [Mum] beschrieben sind. Das Heinbachsche Teiltonzeitmuster(TTZM)-Verfahren [Hei] mit seinen Varianten und die Spektrogramm-Resynthese nach Horn [Hor] sind ebenfalls durchfürbar. Alle diese Verfahren basieren auf der Fourier-t-Transformation (FTT) nach Terhardt [Ter]. Außerdem enthalten sind Funktionen zur Erzeugung und Verarbeitung von Zeitsignalen sowie zur Weiterverarbeitung der verfahrensspezifischen Zeit-Frequenz-Repräsentationen. Das Programmsystem ist kostenlos benutzbar und frei kopierbar (näheres siehe Lizenzmuster).
Das Programmsystem besteht aus einer Reihe von universellen C-Programmen und Shell-Skripten, die über festgelegte Dateiformate Daten weitergeben und meist nur einzelne Verfahrensschritte realisieren. Eine einfache Handhabung der vollständigen Verfahren gewährleisten Steuerungsskripten (Front-Ends), die die in der Dissertation Mummert verwendeten Kürzel als Namen tragen und automatisch alle notwendigen Schritte ausführen. Es sind praktisch nur der Signalname und der Modus Analyse, Visualisierung oder Signalrekonstruktion anzugeben. Dagegen ist die direkte Benutzung einzelner Programme mitunter recht kompliziert, da eine Vielzahl von Parametern anzugeben sind. Es sei gewarnt, daß hierzu bis auf stichwortartige Parameterbeschreibungen kaum Dokumentation vorliegt. (In der README-Datei, die jedem einzelnen Programm beigepackt ist, sind manchmal spezifische Hinweise enthalten. Ansonsten beschränkt sich die Dokumentation auf das nachfolgend Angebotene.)
Die Installation ist auf Linux/Unix-Systemen möglich, über das Ausmaß der Installierbarkeit auf anderen Systemen gibt es keine Erfahrung (siehe auch unterstützte Betriebssysteme). Alle Bedienkonzepte sind textorientiert, es existieren keine Graphic-User-Interfaces. Zur Visualisierung wird auf externe Bildbetrachter zurückgegriffen. Das verarbeitete Audiosignalformat ist "raw". Das erzeugte Grafikformat ist "pbm" oder "pgm".
Der folgende Text ist ein Muster für den Lizenztext, der jedem einzelnen Programm des Programmsystems beiliegt. Einige Programme enthalten eine verfeinfachte Lizenzbedingung 6, die die Verbreitung von Objektcode ohne jegliche Einschränkung zuläßt.
| LIZENZ (Deutsche
Übersetzung - im Zweifel gilt die englische
Version)
für das Software-Paket mit Namen <package-name> bestehend aus den Dateien mit Namen <file-list>
München, 24. Februar 1999 ENDE DER LIZENZ |
Verfahren zur Zeit-Frequenz-Repräsentation (Front-Ends)
Die folgenden Programmnamen werden als Links auf ein Skript namens ctxadmin (K) installiert. Dieses ruft selbstständig weitere Programme des Programmsystems mit den nötigen Parametern auf. Für jedes Verfahren sind die Schritte Analyse, Visualisierung und Rekonstruktion ausführbar, außerdem kann ein ausführlicher Hilfstext angezeigt werden. Es können Signale mit 8, 11,025, 12,8, 16, 22,05, 32, 44,1 und 48 kHz Abtastrate verarbeitet werden.
Datenreduktionsverfahren (Front-Ends)
Die folgenden Programmnamen werden als Links auf ein Skript namens drdadmin (K) installiert. Dieses ruft selbstständig weitere Programme des Programmsystems mit den nötigen Parametern auf. Die Verfahren werden nur simuliert, d.h. für das Eingangssignal wird der Durchlauf durch Coder und Decoder berechnet , Abspeicherung in datenreduzierter Form sowie Visualisierung sind nicht vorgesehen. Es können nur Signale mit 12,8 kHz Abtastrate verarbeitet werden.
Analyse Zeit-Frequenz-Repräsentation aus Zeitsignal
Rekonstruktion Zeitsignal aus Zeit-Frequenz-Repräsentation
Modifikation und Konvertierung von Zeit-Frequenz-Repräsentationen
Alle Programme arbeiten textorientiert im Sinne klassischer Unix-Kommandos: Sie werden jeweils für einen einzigen Lauf gestartet und mit Parametern versorgt, es gibt keine interaktive Veränderung oder Neueingabe von Parametern, alle Eingaben erfolgen als Text. Zur Versorgung mit Parametern existieren historisch bedingt vier unterschiedlich komfortable Konzepte:
Das Programm wird mit Parametern in der Kommandozeile aufgerufen. Bei Aufruf ohne Parameter wird eine Gebrauchsanweisung ausgegeben. Die Identifikation von Parametern und Optionen auf der Kommandozeile ist durch Optionsbuchstaben und/oder eine fest vorgegebene Parameterreihenfolge geregelt.
Eine Ausnahme hinsichtlich der Gebrauchsanweisung betrifft einige Programme, bei denen der Datenstrom über Standard-I/O (stdio) geleitet wird. Diese bleiben bei Aufruf ohne Parameter "stumm" und scheinen zu "hängen" (Abbruch - je nach System - z.B. mit Taste <CRTL-C>, <BREAK> oder <DEL>). Die Ausgabe der Gebrauchsanweisung wird hier mit einer Nonsense-Option erzwungen, z.B. mit -hilfe.
Das Programm wird mit Parametern in der Kommandozeile aufgerufen. Bei Aufruf ohne Parameter wird eine Gebrauchsanweisung ausgegeben, es wird u.a. die Option INFO gelistet.
Das Konzept erlaubt eine flexible Parameterversorgung. Parameterquellen sind (mit steigender Priorität) interne Defaults, eine vom Namen her vorgegebene Default-Parameterdatei, eine explizit angegebene Parameterdatei und schließlich die Kommandozeilenparameter. Dadurch kann man z.B. Parameterdateien als Grundparametersatz laden, per Kommandozeile aber eine Abänderung einzelner Parameter erreichen. Oder man geht z.B. von internen Defaults aus und übergibt auch hier abzuändernde Parameter über die Kommandozeile.
In der Kommandozeile wird der einzelne Parameter über ein Schlüsselwort (Keyword) und einen im nächsten Argument folgenden Parameterwert spezifiziert. Die zulässigen Schlüsselworte listen die Option INFO und INFOPARM auf. In einer Parameterdatei werden pro Zeile nicht mehr als ein Schlüsselwort/Wert-Paar erwartet, getrennt durch TAB- oder Leerzeichen. Der mit "#" folgende Rest einer Zeile wird als Kommentar aufgefaßt.
Die wirksamen Parameter können jederzeit durch Hinzufügen der Optionen INFO oder INFOPARM eingesehen werden, welche gleichzeitig den Start der eigentlichen Rechnung verhindern. Weiterhin kann eine Parameterdatei geladen, durch Kommandzeilenoptionen verändert und unter neuem Namen abgespeichert werden (unter Verwendung der Optionen LOADPARM, INFO und SAVEPARM). Auch kann der Bereich zulässiger Eingaben für die einzelnen Parameter eingesehen werden (Teil der Option INFOPARM).
Es gibt keine Kommandozeilenparameter. Das Programm fragt einen Parameter nach dem anderen ab (Standard-I/O) und beginnt dann mit der Rechnung. Der Stand der Rechnung wird durch einen Zyklenzähler angezeigt. Bei Falscheingabe eines Parameters muß man das Programm abbrechen (je nach System z.B. mit Taste <CRTL-C>, <BREAK> oder <DEL>) und Neustarten.
Zur Automatisierung erstellt man eine Parameterdatei, in der pro Zeile ohne Füllzeichen ein Parameterwert steht, in der Reihenfolge wie interaktiv angefordert. Zum Programmstart lenkt man die Standard-Eingabe auf diese Datei um und verwirft die Standard-Ausgabe (etwa: programm < parameterdatei > /dev/null).
Grundsätzlich gleiches Konzept wie zuvor bei "pseudo-interaktiv", d.h. das Programm fragt einen Parameter nach dem anderen ab. Zusätzlich existiert jedoch ein optionaler Kommandozeilenparameter, der als Pfadname einer Parameterdatei interpretiert wird und der die interaktive Bedienung abschaltet. Zu erkennen ist dieses Konzept daran, daß im nach Programmstart ausgegebenen Text die Meldung "Aufruf mit Parameter Eingabedatei möglich" oder "Eingabedatei als Parameter möglich" zu lesen ist.
Die Parameterdatei enthält auch hier einen Parameterwert pro Zeile, in der Reihenfolge wie interaktiv angefordert. Zusätzlich ist nun aber, eingeleitet durch "#", das Anhängen eines Kommentares auf den Zeilen erlaubt. Dies erleichtert die Identifikation der einzelnen Parameter innerhalb der Datei. Den Quelltexten dieser Programmpakete ist eine kommentierte Beispielparameterdatei <programmname>.par beigefügt, so daß man nicht erst das interaktive "Frage/Antwort-Spiel" durchzuführen braucht, um die benötigten Parameter für eine Parameterdatei zu akquirieren.
Bei Aufruf eines solchen Programms mit einer Parameterdatei werden die gefundenen Parameter zusätzlich auf der Standard-Ausgabe ausgegeben, zusammen mit dem Stand des Zyklenzählers. Dies ist nicht besonders nützlich, so daß man meist die Standard-Ausgabe verwerfen wird (etwa: programm parameterdatei > /dev/null).
Man kann bei diesen Programmen übrigens die Parameterdatei auch wie beim vorigen Konzept durch Umleitung der Standard-Eingabe verwenden (nun etwa: programm < parameterdatei > /dev/null). Der praxisrelevante Unterschied ist also nur, daß Parameterdateien hier Kommentare enthalten dürfen.
Eine durch die festgelegten Dateiformate bedingte Beschränkung des Programmsystems ist, daß im allgemeinen Pegel nur in Schritten von 0,5 dB, Frequenzen nur in Schritten von Signalabtastfrequenz/65536 und Phasen nur in Schritten von 360Grad/256 aufgelöst sind. Einige wenige Programme erlauben die Verarbeitung von Daten in ASCII-Format.
Folge von Abtastwerten im 16bit-Zweierkomplement, Byte-Reihenfolge im Abtastwert maschinenabhängig ("bigendian/littleendian") , aber per Compiler-Flag -DUNNATURAL_BYTEORDER bei der Installation tauschbar. Abtastrate bei den per ctxadmin und drdadmin realisierten Verfahren in vorgegebenen Stufen, bei allen anderen Programmen frei wählbar. Formatkonvertierungen mit sox (z.B. raw <-> Wave/RIFF), Abtastratenkonvertierung mit rateconv (z.B. 8kHz <-> 44,1kHz) möglich.
Repräsentation jeweils durch eine Frequenzdatei und eine Pegeldatei mit einer Folge von Datensätzen, welche die Teiltöne/Frequenzkonturpunkte an einem Auswertezeitpunkt (Heinbachsche Terminologie: ein Teiltonmuster des Teiltonzeitmusters) beziehungsweise die Zeitkonturpunkte nächst eines Auswertezeitpunktes spezifizieren. Der erste Wert eines Satzes legt die Anzahl der im Satz folgenden Pegel- bzw. Frequenzwerte fest. Werte der Frequenzdatei sind immer16 bit breit, vorzeichenlos oder Zweierkomplement, Frequenzwerte sind in Schritten von Zeitsignalabtastfrequenz/65536 quantisiert.Werte der Pegeldatei sind immer 8bit breit und vorzeichenlos. Pegelwerte sind in Schritten von 0,5 dB quantisiert, sie übertreffen 90 dB normalerweise nicht.
Namenskonvention: Einige Programme fordern nur einen Stammnamen an und hängen .mxf und .mxl als Extension für den effektiven Namen der Frequenz- bzw. Pegeldatei an. Es empfiehlt sich daher, sich bei einzeln angeforderten Dateinamen strikt an diese Namenskonvention zu halten!
Die Frequenzdatei ist immer doppelt so groß wie die Pegeldatei. Der Wert am Satzanfang für die Anzahl der Pegel ist wegen der des begrenzten Wertebereiches (8bit vorzeichenlos) undefiniert, wenn die entsprechende Anzahl in der Frequenzdatei > 255 ist. Der Wert in der Frequenzdatei ist dann maßgeblich. Ansonsten bestehen die Einleseroutinen der Programm auf Gleichheit des Anzahl-Wertes in beiden Dateien.
Gleiche Repräsentation wie bei mxf/mxl-Format, zusätzlich tritt eine Phasendatei vergleichbar der Pegeldatei hinzu. In ihr kommen ebenfalls nur vorzeichenlose 8bit-Werte vor, nun aber sind die Phasenwerte eines Konturpunktes in Schritten von 360Grad/256 quantisiert. Für Phasendateien ist Extension .mxp zu verwenden!
Besteht aus einer Pegeldatei wie derjenigen beim mxf/mxl-Format, die Anzahl der Pegelwerte am Satzanfang fehlt jedoch. Diese ist satzinvariant und implizit durch Programmparameter festgelegt. Für den Dateinamen ist die Extension .ftt üblich.
Das Kommando ftttopgm erlaubt es, das ftt-Format in ein Graustufenbild (pgm-Format) und weiter mittels netpbm in beliebige Bildformate zu konvertieren. Dies ist weniger für die Visualisierung interessant, für die der Weg über costximg vorzuziehen ist, wohl aber für eine Modifikation von Spektrogrammen durch Bildverarbeitungsprogramme (Horn). Ein Graustufenbild im pgm-Format kann mit pgmtoftt wieder in das ftt-Format zurückgewandelt werden. ftttopgm benötigt übrigens als Parameter den Wert floor((NFI + GRID - 1)/GRID) (zu NFI und GRID siehe Frequenztabelle).
Besteht aus einer Phasendatei wie derjenigen im mxf/mxl/mxp-Format, die Anzahl der Phasenwerte am Satzanfang fehlt jedoch. Diese ist satzinvariant und implizit durch Programmparameter festgelegt. Für den Dateinamen ist die Extension .ftp gebräuchlich. Bildverarbeitung wie bei ftt-Format.
Diese Format ist mit dem mxf/mxl-Format identisch und wird von den Programmen tzshk und tzmoshk benötigt. Eigentlich scheinen gegenüber dem ftt-Format nur Nachteile zu bestehen, denn die Anzahl der Werte im Satz der Pegeldatei (Extension .shl) wie auch die komplette Frequenzdatei (Extension .shf) liegen durch Programmparameter implizit fest. Der Nutzen diese Formates liegt allerdings darin, daß Pegelspektren, Texturhüllflächen und zeitvariante spektrale Hüllkurven damit von TTZM- bzw. konturverarbeitenden Programmen eingelesen werden können.
Das shf/shl-Format und das ftt-Format sind konvertierbar, sofern nicht Anzahl und Reihenfolge (aufsteigende Frequenzen) im Satz durch Verarbeitung verändert wurden: Man kann die shf-Datei löschen und jederzeit mit fbtab neu erzeugen. Weiterhin kann man addsp oder subsp "mißbrauchen", um die shl-Datei in eine ftt-Datei zu wandeln, und umgekehrt. Als dabei benötigtes zweites Spektrum nimmt man eine Folge von Nullbytes im ftt-Format (z.B. aus /dev/zero). Ist nur die Reihenfolge verändert, so kann man contline dazu "mißbrauchen", wieder nach aufsteigenden Frequenz zu sortieren (MODE fr, TLENL und TLENH gegen unendlich).
Mit dem C-Befehl printf("P4\n%d %d\n", Breite, Hoehe) wird ein ASCII-Vorspann geschrieben. Es folgen in floor(Breite*Hoehe - 7)/8) Bytes zeilenweise die bits des Bildes, beginnend links oben mit dem höchstwertigen bit im Byte. Die bit-Werte 0 und 1 entsprechen weiß bzw. schwarz. Das pbm-Format stammt aus dem Paket netpbm.
Mit dem C-Befehl printf("P5\n%d %d\n255\n", Breite, Hoehe) wird ein ASCII-Vorspann geschrieben. Die nachfolgende Breite*Hoehe Bytes repräsentieren zeilenweise die Grauwerte des Bildes, beginnend links oben. Die Byte-Werte 0 und 255 entsprechen schwarz bzw. weiß. Das pgm-Format stammt aus dem Paket netpbm.
Die Festlegung der Analysefrequenzen, an denen ein zeitvariantes Spektrum berechnet werden soll, geschieht über eine Tabelle (in manchen Programmen auch "Raster" genannt). Da das ftt-Format keine Frequenzinformation speichert, wird diese Tabelle in jedem weiterverarbeitenden Programm neu erzeugt. Programme zur Rekonstruktion aus Konturen benötigen zur Festlegung der Synthesefrequenzen ebenfalls eine Tabelle.
Zur Spezifikation der Tabelle wird von den Programmen die Anzahl NFI der Tabellenfrequenzen, die Startfrequenz F0 in Hz, der Frequenzabstand in Einheit UNIT (Hz, Prozent, ERB, Bark oder spinc) und Maßzahl DF und ein Schrittweitenparameter GRID angefordert. Aufeinanderfolgende Analyse- oder Synthesefrequenzen ergeben sich, in dem an der vorherigen Frequenz die Größe von UNIT in Hz bestimmt und mit DF multipliziert zugeschlagen wird.
Dieses "differentielle" Verfahren erlaubt zwar im Kleinen richtige Abstände, die dadurch realisierte Frequenztransformation (außer bei Hz) weicht im Großen aber von der richtigen um so mehr ab, je größer DF ist. Für die Verfahren ist diese Abweichung egal, solange alle Verfahrensschritte die gleiche Transformation verwenden. Dazu müssen F0, UNIT und DF überall gleich sein. Um die Frequenzabstände z.B. bei der Textur vergrößern zu können, ohne die Transformation zu beeinflussen, gibt es den Parameter GRID. Er besagt, jede wievielte Tabellenfrequenz ein spektraler Stützwert ausgegeben oder eingelesen werden soll. Die Tabellenfrequenzen können mit fbtab gelistet werden. mit Zur Visualisierung rechnet costximg die Tabelle übrigens in eine Transformation um, die auch im Großen richtig ist.
Das Programmsystem wurde auf folgenden Betriebssystemen getestet:
Folgende Software sollte bereits installiert sein:
[Suchbegriff in eckigen Klammern, mit dem in öffentlichen ftp-Servern gesucht werden kann, z.B. über http://www.ftpsearch.com; die angegebenen Nummern entsprechen nicht unbedingt den aktuellen Versionen]
Das komplette Programmsystem ist im ftp-Verzeichnis für den Download als Quellcode im gzip/tar-Archiv unter dem Namen swmumdis-xxxxxx.tar.gz abrufbar. Die Dateigröße beträgt ca. 1,5 MByte. Ein Unterverzeichnis mit Namen swmumdis hält alle Programme des Programmsystems auch zum Einzelabruf bereit. Shell-Skripts (u.a. alle Front-Ends) und verfügbare Dokumentation sind zusammengefaßt unter den Namen scripts-xxxxxx.tar.gz bzw. doc-xxxxxx.tar.gz abrufbar.
Nach dem auspacken mit gzip und tar in das Verzeichnis swmumdis-xxxxxx wechseln. Dort make aufrufen, alles weitere erklärt sich selbst. Besondere, im Makefile editierbare Optionen sind nachfolgend nochmals aufgeführt:
Homepage für Dissertation Mummert und SWMUMDIS
Copyright (c) 1998 Dr.-Ing. Markus Mummert
$Id: overview.html,v 2.15 2015/07/27 20:38:51 mummert Exp mummert $