Digitale Signalverarbeitung erklärt

Status
Für weitere Antworten geschlossen.
Hallo!

Schön, daß auch mal die theoretische Seite der digitalen Audio- Videotechnik hier im Forum eine Erwähnung findet. Normalerweise benutzen wir ja nur die Tools und drehen an den Reglern eines EQ, etc. "im Computer", ohne uns überhaupt Gedanken zum "Wie funktioniert das eigentlich?" zu machen. Danke, Dude! Das Thema DSP ist natürlich sehr speziell und erreicht damit sicher nicht die "Klickzahlen" eines "Topthemas" in dieser Rubrik. Dafür gibt es andere Anlaufstellen im Internet. Man kann also nicht erwarten, daß hier die "Top-Spezialisten" in Sachen DSP im Forum rumgeistern.

Wer aber mit - hier bei uns speziell - Audio zu tun hat, einen PC in einer gängigen Programmiersprache programmieren kann, und dann auch noch ein bestimmtes Problem lösen möchte, ist mit den in diesen "Tuts" aus dem Internet vermittelten Grundlagen (auch in Form von Programmcode in C-64-BASIC) bestens bedient!

Wer eine Programmiersprache einigermaßen beherrscht, der kann auch eine andere Sprache lesen! (Von selbst "Schreiben" rede ich nicht!) Man muß sich halt etwas in die Struktur der "fremden" Sprache - z.B "FORTAN-77" einlesen, damit man sie versteht. (Viele alte Werke zum Thema "DSP" verwendeten diese Programmiersprache, weil sie halt für diese Zwecke gedacht war.)

http://de.wikipedia.org/wiki/Fortran

Wer "nur" C kann, kann aber (mit Sicherheit völlig problemlos) einen in "C-64-Basic" vorgegebenen Programmcode auch richtig in C übersetzen. Wichtig ist doch nur, daß die Übersetzung "stimmt" und beim Test bei gleichen Eingangsdaten bei beiden Codes "hinten" das selbe Ergebnis rauskommt. (Denkt besonders an die "Laufweite" von Schleifen aller Art! Kleiner Fehler - große Wirkung - mitunter schwer zu finden!) Für die "Weicheier"gibt es aber auch "Übersetzer", die meinetwegen "BASIC" direkt nach "C" übersetzen. Das hat aber den Nachteil, daß man mögliche Übersetzungsfehler nicht erkennt, weil man die Übersetzung gedanklich ja nicht selbst nachvollzogen hat.

Auch wenn es jetzt so manchen "Hobbyprogrammierer" mächtig in den Fingern juckt, mal selbst einen "kleinen EQ" zu basteln, die letzte Mathestunde (egal ob Abi oder nicht) liegt selbst bei mir schon 30 Jahre zurück. Die höhere Mahtematik braucht man im normalen Leben eigentlich nicht. Man vergisst unnützes Wissen schell. Wenn man dann nach vielen Jahren in diesen PDF-Dateien diese komplexen Formeln sieht, dann sagt man vorschnell: "Nee - das begreif ich nicht, krieg es nicht mehr auf die Reihe!" (Ja, ich bin auch faul!)

Schade eigentlich, denn wer einigermaßen anständig programmieren kann, kann mit Mathematik nicht generell auf Kriegsfuß stehen. Es fehlt doch eigentlich nur ein Beispiel, um zu zeigen, wie diese oder jene komplexe Formel funktioniert. Und darum nimmt uns der Autor der unten verlinkten Website an die Hand, gibt es diese Beispiele in "BASIC" und wir haben erstmal ein "Erfolgserlebnis"...

Natürlich hat man danach erstmal nur den rudimentären Kern des "EQ"-Programms, damit kann man aber arbeiten! Es fehlt noch die Dateneingabe (z.B. Samples über "Line-In" reinholen, oder die Ausgabe (z.B. die gefilterten Samples über "Line -Out" auszugeben oder auf Festplatte zu speichern). Aber wer sich an ein solches Projekt wagt, wird das sicherlich problemlos können.

"Richtig schick" wird es, wenn man dann noch ein GUI programmiert, wo man "den Frequenzgang" des Filters live mit der Maus "zeichnen" (und hören!) kann (sowas findet ihr heute in jedem Soundeditor in der "EQ-Abteilung") oder spezielle Funktionen anwenden kann. Letzteres findet ihr sicherlich seltener.

Gibt es denn mittlerweile beispielsweise einen kostenlosen "Handyton-Killer"?


Vor ziemlich exakt fünf Jahren haben wir hier ein solches Filter gebraucht.
http://www.radioforen.de/index.php?threads/handy-störgeräusch-im-interview.22944/page-2#post-386957

Ich habe damals nichts weiter gemacht, als kuzfristig ein schon bestehendes Programm zur Entzerrung von Schallplatten etwas umgeschrieben. Ich habe nur den "gewünschten Frequenzgang" vorgegeben. Die Grundlagen sind die selben.

Wer also selbst "sowas" schreiben will, sollte mit der Theorie etwas vertraut sein oder sie hier

http://www.dspguide.com/

nachholen. Richtig interessant wird es dann nämlich im Kapitel 17 - Custom Filters

"This is DSP at its best.", wie im Einleitungstext zu lesen ist. Und so ist es auch, denn damit (auf deutsch heißt das glaube ich "Frequenzabtastfilter") kann man jeden (!) gewünschten Frequenzgang im Rechner (mit der Maus) "hinbiegen". Mit analogen Bauelementen in Filtern ist sowas praktisch nicht möglich!

Wenns dann am Ende auch funktioniert, macht DSP richtig Spaß!


Ich hoffe, ich konnte die leicht müden (Old-School)Programmierer hier etwas aufmuntern! Glaubt mir: Selbst etwas zu programmieren und dabei in die Röhre zu gucken, ist besser, als am Wochenende in die Röhre zu gucken und sich dabei die Rübe aufweichen zu lassen!
 
Natürlich hat man danach erstmal nur den rudimentären Kern des "EQ"-Programms, damit kann man aber arbeiten! Es fehlt noch die Dateneingabe (z.B. Samples über "Line-In" reinholen, oder die Ausgabe (z.B. die gefilterten Samples über "Line -Out" auszugeben oder auf Festplatte zu speichern). Aber wer sich an ein solches Projekt wagt, wird das sicherlich problemlos können.

Man kann die Winamp dsp lib nutzen.
"Daten ein und ausgabe"
 
Man kann. Aber sollte man?


Ich habe gerade mal gegoogelt und mit der Eingabe

Winamp dsp lib

über 21 Mio. Treffer gefunden. Die ersten drei, vier Treffer habe ich mal schnell "überflogen", aber nicht gleich die passende Info gefunden. Ich kenne das API dieser Lib nicht, gehe aber mal davon aus, daß ich 95% der angebotenen Funktionen nicht brauche. Außerdem müßte ich erst die Aufrufkonventionen lernen. Das dauert mir für eine "billige" E/A-Geschichte einfach zu lange. Da schreib ich den Code doch lieber (einmal) selbst, kann diesen Code später (in anderen Programmen) wiederverwenden und habe keinen Streß.


Wie ich oben schon schrieb, benutzen nur "Weicheier" irgendwelche "Code-Übersetzer". Und genauso kratzen auch die Benutzer solcher Libs nur an der Oberfläche einer Programmiersprache. Sie kennen das vom Betriebssystem (hier im Beispiel "Windows"; das "Win32-API") vorhandene API nicht und verlassen sich damit auf fremden Code. Am Ende wird eine Softwareschale über die andere gelegt ("High Level"- Sprachen) und letztendlich ein 10 Megabyte Download mit Installation "für so ein bisschen Scheiß" fällig. Und das nur, weil viele angebliche Programmierer keine Ahnung vom Progrmmieren haben. Bekanntlich nenne ich Programme dieser Art "Klumpentools".

Dieses unten im Bild gezeigte "Windowsprogramm" hat eine Größe von 60 kB und filtert ganz gut Handy-Störungen raus. Wie du, Nobier, sicher erkennst, verwendet das Programm die "Low-Level" Audiofunktionen aus WINMM.DLL. Diese DLL befindet sich - gemeinsam mit anderen DLLs, die praktisch das Erscheinungsbild von "Windows" nach einer Neuinstallation ausmachen - auf dem Rechner! Ich muß also rein gar nichts installieren!

Wenn ich diese CNA.exe zippe, kommen 26 Kilobyte raus! Würde ich dieses Zip per Mail verschicken, mußte ich den Empfänger heute explizit darauf hinweisen, daß es sich dabei nicht um einen Virus handelt! So bekloppt ist die Welt mittlerweile!

Grüßle
 

Anhänge

  • cna__klein_aber_fein_mit _winmm_dll.gif
    cna__klein_aber_fein_mit _winmm_dll.gif
    123 KB · Aufrufe: 13
Lieber Zwerg,

ich weiss nicht so recht, was ein allgemeiener Rant gegen modulare Softwareentwicklung und Wiederverwendung von Komponenten mit den erwähnten Videos zu tun hat. Ja, aufgeblähte Software, die fast nichts macht, das dafür langsam, ist die Pest der Neuzeit. Andererseits ist es - gerade für nicht sehr erfahrene Entwickler - extrem schwierig, hier die richtige Balance zu finden zwischen Dingen, die man selbst implementieren sollte, und Dingen, die man lieber als vorhandene Bibliothek einbinden sollte.
Und gerade dann, wenn einem vorhandene Implementierungen unnötig kompliziert erscheinen, ist extreme Vorsicht geboten, denn dann ist die Gefahr, dass man die Schwierigkeit einer korrekten und guten Implementierung einfach nicht erkannt hat, am größten. Und hier kommen wir eventuell doch zusammen, denn um die Herausforderungen zu sehen, hilft nur, das Problem wirklich verstanden zu haben. Ein guter Weg dahin ist der von dir beschriebene, einfach mal die Grundlagen in die Hand nehmen und alles selbst implementieren. Nur dass am Ende nicht selten die Erkenntnis steht, dass der eigene Code eben doch nicht besser ist als das, was andere Leute über lange Zeit mit hohem Aufwand schon vorher entwickelt haben.

Und um mal wieder wegzukommen von der Softwareentwicklung, so ähnlich verhält es sich auch bei der "normalen" Nutzung der Technik - hier: digitale Übertragung von Audiosignalen. Wir alle stöpseln munter AES/EBU Strippen von A nach B, digitalisieren Aufnahmen, wandeln Sampleraten und diskutieren, wo jetzt eigentlich am besten Vollausschlag ist. Das vollständig digitale Radiostudio ist jetzt die Norm. Da helfen die Grundlagen - sofern nicht vorhanden - dem Verständnis, auch wenn man keine DSPs programmiert. Und deshalb sind solche Videos und deren Inhalt hier genau richtig, und zwar für alle, die daraus noch etwas lernen können.
 
Und genauso kratzen auch die Benutzer solcher Libs nur an der Oberfläche einer Programmiersprache

Pfffff. Um so intensiver beschäftigen sich die Weicheier mit dem eigentlichen.........

Hat doch auch Vorteile, Schnittstellen zu nutzen, die auch Systemunabhängig verwendet werden können.... z.b. Plugins...VST...
 
@dude: Ich habe bisher noch nichts zu den Videos geschrieben, weil ich sie mir noch nicht angesehen habe. Ich habe bisher nur den (ellenlangen) Text auf der Webseite überflogen und mir die beiden Videos gesaugt. Und klar, man muß und sollte nicht versuchen, das Rad immer neu zu erfinden!


@Nobier & All: Natürlich muß man immer Software-Schnittstellen bzw. die angebotenen APIs benutzen. Das ist nicht die Frage, denn wenn man unter Windows programmiert, landet jeder Funktionsaufruf letztendlich in einer der immer vorhandenen System-DLLs (Kernel32, User32 usw.).

<kleiner Einschub>
Ich komme (bekanntlich?) aus der C-64-Ecke und habe daher sehr schnell begriffen, daß das eingebaute BASIC verflucht langsam ist ("Interpretersprache", die "Token", falls euch das noch was sagt). Ich habe daher "Assembler" (bitte nicht mit "Maschinensprache" verwechseln) gelernt und konnte so Teile meiner BASIC-Programme in Assembler schreiben und damit um den Faktor 100 - 200 beschleunigen. Das waren "Welten" bei 985 kHz Taktfrequenz! Und notfalls hat man auch noch das ROM "ausgeblendet", um den darunterliegenden RAM-Speicher nutzen zu können. Das waren "wilde" Zeiten - aber halt auch Lehrjahre, die bis heute prägen. Ich reagiere daher immer etwas "empfindlich", wenn ich etliche Megabyte für ein "lächerliches" Programm downloaden und - als Krönung - sogar noch installieren muß.

Bevor ich nun weitere "Schwänke aus den Tiefen der Betriebssysteme auf Assemblerebene" erzähle und dabei noch ins Schwärmen gerate, schnell zurück zu den Hochsprachen.
</kleiner Einschub>

Ich habe unter Windows mit "VisualBasic 4.0" angefangen. Das ist also schon lange her. Schönes Arbeiten, denn man hat ruck-zuck die Benutzeroberfläche "zusammengeschoben". Dann noch schnell die "OnClick()" Prozeduren mit Code gefüllt und fertig. Fertig? Nee, nee, denn dann kommt ja noch das "Verpacken", damit das Programm beim Benutzer auch funktioniert. Sprich: Die ganzen Laufzeitbibliotheken ("vbrun*" oder wie die alle hießen) müssen mitgeliefert werden. Aus einem simplen Programm wird so halt unweigerlich ein "Klumpentool".

So schön wie "Rapid Application Development" (RAD) ist, man bezahlt dabei mitunter einen sehr hohen Preis - nämlich in Form der Ausführungsgeschwindigkeit eines Programms. Damals, zu "VisualBasic 4/5"-Zeiten, konnte der BASIC-Compiler, glaube ich, den Code noch nicht in "Nativen Code" (oder "systemnahen Code"?) wandeln. Evt. war das auch nur den "Profiversionen" vorbehalten. Das kann ich heute echt nicht mehr sagen. Ich habe damals aber mal einen Versuch gemacht, bin dabei richtig erschrocken und habe dann ganz schnell "C" gelernt!

Wer VB auf dem Rechner hat, kann den Versuch ja mal machen. Davon erzähle ich aber nur auf Nachfrage, denn sonst wird das Posting (schon wieder) zu lang. ;)


Mir ging es primär darum, die Frage zu klären, ob ich für die simple Aufnahme bzw. Wiedergabe von Audio eine externe Lib, wie halt die von Winamp, benötige, die ich dann ja im Ernstfall "mitliefern" muß. Die Antwort darauf ist nein, denn das kann auch die "windowsinterne" winmm.dll.
 
Wobei zu erwähnen wäre, dass MME (winmm.dll) schon seit Jahren nicht mehr Stand der Technik ist; als Programmierschnittstelle existiert die DLL zwar auch auf aktuellen Windows-Installationen noch, es ist aber nur noch eine Emulation, die auf die "native" Audio-Schicht der jeweiligen Windows-Version aufsetzt: Bis Windows XP DirectSound, seit Windows Vista dann WASAPI.

Würdest du dein Programm also mit möglichst wenig Overhead und nahe an der nativen Schicht arbeiten lassen wollen, müsstest du also je nach Windows-Version DirectSound oder WASAPI verwenden. Deren Programmierschnittstellen sind aber jeweils so komplex, dass man am Ende doch ganz froh ist eine Library zu haben, die den Umgang mit den APIs etwas vereinfacht.

Ich empfehle dazu die BASS.DLL sowie BASSWASAPI.DLL von www.un4seen.com. Beide sind zusammen nur ca. 100kB groß.
 
@yps77: Ich kenne die Enwicklung ja auch etwas. "Direct-X" und damit "DirectSound" sind natürlich die erste Wahl. Aber bitte mal langsam! Wir sollten einen Gang zurückschalten und dann versuchen das Thema langsam zu erklären.

Ich habe hier beispielsweise die MSDN von 1996 vorliegen und möchte, daß wir versuchen,. Direct-X - damals noch in der Version 2 /3 vorliegend, versuchen hier "an den Mann" zu bringen. Darüber können wir uns gern intensiver unterhalten.


Bei dieser ganzen Unterhaltung beachte bitte folgenden Punkt: Ich möchte, daß ein Programm, welches von mir geschrieben wurde, völlig problemlos ab dem OS "Windows 95" läuft. Das funktioniert normalerweise, weil ich einige Regeln beachtete.


Ich beachte diese Regeln, weil ich - das bilde ich mir zumindest ein - ein intimer Kenner des "Windws API" bin und unter diesem OS programmiere. Ein Programm von mir mußt du auch nicht installieren - gib mir maximal 100kB Platz auf deiner Festplatte und ein "kleines" Programm von mir wird funktionieren! Für dieses Programm würde ich sogar einen meiner zehn Finger opfern! Ich weiß was ich tue und kann es mir einfach nicht leisten, euch irgendwelche "Scheiße" anzudrehen. Programmierfehler passieren, die habe ich aber immer ganz schnell gefixt.

Bisher waren meine Tools aber auch nur ganz klein und damit "Kinderkacke". Sollte irgendein Progamm von mir hier im Forum größer werden, kündige ich das mit Sicherheit vorher an!


Bevor du antwortest: Wenn du "zu neue" API benutzt, lauft dein Programm halt nicht mehr "ganz einfach" oder überhaupt auch unter "Win95". Bitte jetzt keine überschnelle, unüberlegte und "flapsige" Antwort wegen "Win95"! Du weißt, was ich meine! Ohne Not, sollte man "alte" OS nicht "ausschließen".




.
Ich habe mir nun mittlerweile auch die beiden Videos angesehen. Schön gemacht und gut erklärt!! Diese beiden Videos sollte man sich wirklich reinziehen! Wer die deutschen Untertitel aktiviert, verpassst aber einiges an "Witz". Bitte zwingt euch, Englisch zu verstehen! Spult lieber mehrmals 20 Sekunden zurück!

Rein technisch (auch vom gezeigten Versuchsaufbau) gibt nichts zu meckern! Die haben ganz bewußt die teuerste analoge Technk ("State of the Art") in Form von "Tektronix"- Gerätschaften aufgefahren! Das volle Programm! Boha! Geräte, die so sündhaft teuer sind, daß uns allen sicher die Zunge raushängt. Lecker, aber privat leider unbezahlbar! Beruhigt euch! Im Normalfall braucht niemand von uns diese Gerätschaften jeden Tag! "Nice to have" - keine Frage! ;) Diese Geräte sind aber viel zu schade, um nur am Wochenende für eure "Piratensender-Basteleien" eingesetzt zu werden! *hüstel*

Es mag zwar etwas überheblich klingen, aber als ich dieses Video gesehen habe, mußte ich mehrmals lachen, ganz einfach deswegen, weil ich eine gewisse Nähe gespürt habe. Als er die Audiokassette in der Hand hatte und von maximal 9 Bit sprach, kam mir sofort dieser alte Thread wieder ins Gedächtnis. Ja, dieses Thema hatten wir hier auch schon!

Ende Dezember 2008 schrieb ich hier im Forum "Wenn der Pegel nie unter -15dbFS fällt (Optimod rulez), kann man völlig problemlos auch mit 9 Bit Auflösung senden... Im Auto hört das niemand. *aua*"


Full story: http://www.radioforen.de/index.php?threads/dynamikkompression-auf-audio-cds.26352/
 
Die haben ganz bewußt die teuerste analoge Technk ("State of the Art") in Form von "Tektronix"- Gerätschaften aufgefahren! Das volle Programm! Boha! Geräte, die so sündhaft teuer sind, daß uns allen sicher die Zunge raushängt. Lecker, aber privat leider unbezahlbar! Beruhigt euch! Im Normalfall braucht niemand von uns diese Gerätschaften jeden Tag!

Hast du das Video wirklich gesehen?

Zwei der drei Geräte im zweiten Video sind von HP, und er hat extra betont, dass diese alten aber dennoch guten Geräte für wenig Geld bei eBay erhältlich sind und ideal für Hobbyisten geeignet sind.
 
Hast du das Video wirklich gesehen?

Natürlich nicht! Aber als ich mir wohl nur einbildete die beiden Videos zu sehen, habe ich - pöse wie ich bin - daran gedacht, die Videos gleich im "Analog-Forum" zu verlinken, um damit etwas "zu zündeln". ;) Die Jungs dort "stehen" auf analoge Signalwege und die "Treppenstufen-Geschichte" konnte man dort in der Vergangenheit auch oft lesen.


Zwei der drei Geräte im zweiten Video sind von HP, und er hat extra betont, dass diese alten aber dennoch guten Geräte für wenig Geld bei eBay erhältlich sind und ideal für Hobbyisten geeignet sind.

Schon klar. Ich habe, weil ich mich jahrelang nicht mit solchen Geräten beschäftigt habe, auch gestaunt, wie billig diese Geräte heute sind. Eigentlich ist das aber kein Wunder. Dieses Tektronics 2646 war damals auch "mein Traum". Ich habe leider keinen alten "Conrad"-Katalog gefunden. 5000 DM mußte man aber Mitte der Neunziger dafür einplanen. Als "Gebrauchtgerät" darf daran heute halt nichts kaputtgehen, zumindest nicht die Bildröhre. (Ich besitze "nur" ein russisches 10 MHz Osszi von 1989, aber mit Schaltplan. Solange die Bildröhre nicht ihren Geist aufgibt, funktioniert das Teil und läßt sich (mit der Bedienungsanleitung) sogar noch problemlos und im Rahmen der "Strichbreite" auf dem Schirm auch relativ genau kalibrieren. Ist halt "russisch Technik"! Bisher habe ich nur einen neuen Tastkopf (1:1/1:10) gekauft.)
 
Und? Wie schätzt du die beiden Videos ein - so als Grundlage für "Anfänger"? Kann ich nebenbei hoffen, daß mich irgendwelche Leute mit ihren "digitalen Soundkreationen" demnächst nicht mehr ungefragt behelligen?

Mal sehen.
 
Mehr kommt nicht?

núr we11 Dú "moviez" 5chR31Bs7, bÏsT dU n0cH LaNGe n1ÏCT "31337"! weR se1BsT Ïn 3Ïner Ni0RMåLên UNTerh4LTúng Kêin3 Gr0ßbúcH57ab3n KeNN7, 157 e1NfaCh 3ÏN Zúrückg3b1iêb3n3s 5CrÏp7-Kiddy!

t3X7 VeR5t4ndeN?
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben