Hi, in der Uni sollen wir mit dem Siemens C167 Sprache aufzeichnen und später wiedergeben. Nachdem ich mich in das Thema DSP eingelesen habe, denke ich das ich dazu DFT (bzw. zur späteren Berechnung dann FFT) nutzen muss. Leider habe ich nach 2 Büchern und intensiver Recherche im Netz noch immer keine Ahnung was ich genau machen muss. Die DFT soll mir zu einem abgetasteten Sginal die Frequenzen und ihre Amplituden liefern aber wie das genau laufen soll ist mir schleierhaft. Zudem brauche ich komplexe Zahlen für die Berechnung - der C167 unterstützt nicht mal floating point wodurch man sich routinen dafür erstmal mühselig per hand schreiben müsste. Hab ich irgendwas falsch verstanden? Und kann mir irgendwer grob erklären was ich mit den Abtastwerten des ADC machen muss? Vielen Dank im Voraus :)
Hallo Michael,
> ... wir mit dem Siemens C167 Sprache aufzeichnen und später wiedergeben
Wozu brauchst Du für eine Sprachaufzeichnung eine DFT?
(Zur Wiedergabe bräuchtest Du dann auch die inverse DFT).
Sprachaufzeichnung:
1) A/D-Wandlung
2) Werte im Speicher ablegen
Sprachwiedergabe:
1) Speicher auslesen
2) Werte an den D/A
Ich kenne den C167 nicht, habe aber gelesen, dass er über eine
SSC-Schnittstelle verfügt, um eine serielle Kommunikation mit A/D-
D/A-Wandlern zu ermöglichen.
Alternativ kann die Wandlung (A/D und D/A) auch direkt über die Ports
des uC erfolgen:
Das Stichwort lautet 'PWM' (Pulsweiten-Modulation).
Gruß
Nils
Hmm jo geht :D Aber warum wird in der Versuchsbeschreibung bei uns ellenlang Fouriertransformation beschrieben. Wir sollen die aufnahme auch noch komprimieren - braucht man das dafür??
Hallo Michael, > Wir sollen die aufnahme auch noch komprimieren Davon hast Du nichts geschrieben. Du sollst offenbar folgendes machen: Aufnahme: 1) Werte in einem Zeitfenster abtasten und einer FFT unterwerfen 2) Die FFT-Daten (Amplituden und Phasen) reduzieren (Komprimierung) 3) Werte abspeichern Wiedergabe: 1) Eventuell Werte aus dem Speicher dekomprimieren (hängt davon ab, wie Du komprimiert hast) 2) Daten einer inversen FFT unterwerfen 3) Resultat an den D/A geben Zum Verständnis: Du tastest Dein Audiosignal in einem Zeitfenster ab (mehrere Werte also). Die DFT liefert Dir die Amplituden und Phasen bei festen Frequenzen. Diese Daten bilden dann die Grundlage für eine Datenreduktion (Komprimierung). Beim Abspielen wendest Du dann die inverse DFT (klar FFT) an: Aus den Amplituden und Phasen bei festen Frequenzen wird dann wieder ein Signal im Zeitbereich (Amplitude vs. Zeit), dass Du abspielen kannst. > Zudem brauche ich komplexe Zahlen für die Berechnung Dafür gibt es den Datentyp vector oder Du verwendest Arrays > der C167 unterstützt nicht mal floating point Durch Normierung lässt sich eine FFT auch in Integer-Arithmetik durchführen (-> Lookup-Tables für sin u. cos) FFT: Einfach mal im Forum suchen oder googeln - hier gibt es etliche Beipiele auf diversen MüPehs... ... siehe auch Elektor oder in Eurer Uni-Bibliothek: In der Zeitschrift 'Elrad' gab es in den 1990ern eine Serie 'Signalverarbeitung in C'. Da findest Du eine konkrete Implementierung einer FFT. Kompression: Welches Kompressionsverfahren Du benutzen sollst, sollte eigentlich (zumindest als Hinweis) in Deinem Script stehen. Es gibt einfache Algorithmen, die auf einer rein informationstechnischen Sicht beruhen (-> z.B. LZW, ZIP) und zusätzlich psychoakustische Verfahren (-> z.B. Ogg, speech, mp3). Falls wirklich nichts in Deinem Script steht, einfach mal den Assi fragen, in welche Richtung es gehen soll. Ohne konkreten Input wird Dir da keiner weiterhelfen können. Gruß Nils
Als Komprimierungen wurden folgende Verfahren als möglich erwähnt: - Diskrete Cosinustransformation (mit der Anmerkung das es schwer zu impl. ist) - Pausenerkennung und kodierung solcher - Entropiekodierung von Delta-Werten - logarithmische Kodierung Mein Problem ist ja, das alles in Assembler geschrieben werden muss. C Code kann ich dann natürlich als formale Algorithmusbschreibung nutzen aber derlei Datentypen stehen mir natürlich nicht zur Verfügung. Dies würde Aufgabe aber ungleich komplexe machen und IMO niemals lösbar sein in so kurzer Zeit denke ich. Ich muss da die Betreuer nochmal anprachen, wenn sie denn mal da sind. ^^
Hallo Michael, > Diskrete Cosinustransformation (mit der Anmerkung das es schwer zu impl. ist) Das wäre die Frage: Immerhin spielt die Cosinustransformation im Reelen, so dass Du Dir die Assembler-Programmierung von komplexen Zahlen ersparen könntest. In dem Zusammenhang ist auch die 'Wavelet-Transformation' interessant (Kompression und reeles Fundamentalsystem). Literatur: Numerical Recipies > Pausenerkennung und kodierung solcher Am einfachsten zu machen, indem Du Daten unter einer definierten Schwelle nicht speicherst, sondern nur deren Länge vermerkst. > Entropiekodierung von Delta-Werten Kenn ich mich nicht genau mit aus. Geht aber in die Richtung 'LZW', also Komprimierung unter Berücksichtigung der Lauflänge von Codefolgen > logarithmische Kodierung Kenn ich mich nicht genau mit aus. Geht aber in die Richtung 'psychoakustische Verfahren'. Beipiel (sehr plakativ!): Wenn die FFT in einem Zeitintervall einen lauten hohen Ton leifert und gleichzeitig einen tiefen Ton mit geringer Amplitude, kannst Du den tiefen Ton weglassen, weil nur der laute, hohe Ton wahrgenommen wird (-> psychoakustische Maskierung). Ok, da ist die Einarbeitung sehr komplex - die Quellensuche wird auch schwer, weil in diesem Bereich viel Wissen patentiert ist. > Dies würde Aufgabe aber ungleich komplexe machen und IMO niemals lösbar sein in so kurzer Zeit denke ich Wie lange hast Du denn Zeit? Gruß Nils
Nachtrag: Wenn die Zeit so kurz ist und Assembler angesagt ist, wieso dann nicht einen pragmatischen Weg einschlagen: - Das Fourier-Gesumpse weglassen - Die psychoakustische Verfahren den Frauenhofern überlassen Stattdesssen: Sprachaufzeichnung: 1) A/D-Wandlung 2) Kodierung der A/D-Werte und Schwellendetektion zwecks Pausenerkennung 3) Datenkompression mit LZW oder ähnlich 4) Werte im Speicher ablegen Sprachwiedergabe: 1) Dekodierung des eigenen Formats (Pausenerkennung) 2) Dekompression des LZW 3) Werte an D/A Du solltest Deine Betreuer fragen, ob das reicht - Du hättest damit eine Implementierung, die im Wesentlichen ohne Numerik auskommt. Gruß Nils
Wenn man den FFT nicht überlappend anlegt, hat man schöne Sprünge, die sich als Knattern bemerkbar machen. Besser vorher eine Fensterfunktion verwenden und 50% Überlappung wählen. Im Grunde genommenn müsste man auch da die Phasen anpassen aber aus meiner Erfahrung ist das Knattern so weniger hörbar. Ich würde allerdings die Methode 'Entropiekodierung von Delta-Werten' verwenden. Stichwort und erste Informationen: http://de.wikipedia.org/wiki/ADPCM Die einfachste Methode wäre sicherlich 'logarithmische Kodierung'. Stichwort und erste Informationen: http://de.wikipedia.org/wiki/A-law
@Forian: Deine Vorschläge laufen auch auf eine mehr oder weniger algorithmische Lösung hinaus. Ich denke, numerische Verfahren, insbes. in Assembler programmiert, liefern sehr viel 'Fallstricke'. Siehst Du das ähnlich? Gruß Nils
Es wird wohl darauf hinauslaufen (müssen) zumindest mit Festkommazahlen zu rechnen. Wenn in der Aufgabenbeschreibung schon von FFT die Rede ist, dann wäre doch eine Pausenerkennung, wie Du sie vorgeschlagen hast, vermutlich zu profan. Ich könnte mich auch vorstellen, dass es nicht um Codierungsverfahren, sondern um Signalverarbeitung geht und da die LZW-Geschichte unpassend wäre. Davonab war da nicht mal irgendetwas bezüglich Patenten bei LZW? Sicherlich wäre es für die Profs schöner, eine Huffman-Komprimierung zu sehen, wenn man denn so etwas machen wollte. Wie gesagt, ich verstehe die Aufgabe eher so, dass man sich zumindest gedanklich mit Codecs, wie z.B. G.726 oder G.711 auseinandersetzen soll. Mir fielen die Begriffe "Sprache", "Kompression" und dann die Stichworte wie FFT, Logarithmus, Delta-Codierung etc. auf. Klar ist das keine Aufgabe, die man 'mal eben' auf einem C167 unter Assembler umsetzt, aber für einen angehenden Akademiker in diesem Gebiet sollte das lösbar sein.
Wir haben bis 11.07. Zeit und es sind pro Woche 90 Minuten angesetzt. Diese Angabe ist aber utopisch niedrig und würde bei keinem der Versuche reichen. Praktisch arbeit man ca. 8 stunden pro Woche dran - in dreier Teams. Das macht die Sache nicht leichter, da der Programmierer dann auch immer erklären muss was er macht. Aber auf jedenfall Danke schonmal für die vielen guten Infos. Mich interessiert das ganze ja auch privat. :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.