[Rumgucker]

Wenn ich auch noch ne Wavedatei aufnehmen kann, dann hab ich gewonnen. Dann kommt auch Deine Testdatei zum Zuge.

[Bandre]

Habe hier Code in PureBasic für die Aufnahme, soll ich den mal posten?

Edit: geht auch einfacher

[Rumgucker]

Ja.. das hilft, denke ich . Dankeschön.

[alfsch]

...in pure basic hätte ich das ganze schon fixfertig...für mein Lautsprecher-messprogramm (das ich irgndwann weiter mache... )
--soll ich das mal rauskramen? (die win-api aufrufe sind ja die selben, die auch in C verwenden kannst)

[Bandre]

Zitat:Original geschrieben von alfsch

...in pure basic hätte ich das ganze schon fixfertig...

Boah das gibt

[alfsch]

aaa....bzgl sound duplex wiedergeben und aufnehmen ---- viel mehr kanns noch nicht, sonst hätte ichs schon mal gepostet

[alfsch]

so etwa....play+rec


Procedure playrecprep() **********************************************


; devnr=waveOutGetNumDevs_()

err= waveOutOpen_(@handle , #WAVE_MAPPER, @wavtype , 0,0, #CALLBACK_NULL | #WAVE_FORMAT_DIRECT )
err= waveInOpen_(@handlein, 0, @wavtype, 0, 0, #CALLBACK_NULL)

err= waveOutPrepareHeader_(handle, @pwh, SizeOf(pwh))
err= waveInPrepareHeader_(handlein, @rwh , SizeOf(rwh))


; EndIf
; Delay(50)

EndProcedure

Procedure playrec() ***************************************************
Delay(50)

err= waveInAddBuffer_(handlein, @rwh, SizeOf(rwh))
err= waveInStart_(handlein)
err= waveOutWrite_(handle, @pwh, SizeOf(pwh))

EndProcedure

[Rumgucker]

Sieht super-einfach aus. Das kann ich aber auch mühelos nach C portieren, wenn ich da ähnliche Funktionen zur Verfügung hab.

...wird ein spannendes Wochenende... "Gucki will was lernen tun"

[Rumgucker]

Zitat:Original geschrieben von Bandre

Zitat:Original geschrieben von alfsch
...in pure basic hätte ich das ganze schon fixfertig...

Boah das gibt

Basic war die allererste Programmiersprache, die ich richtig gelernt hatte (natürlich gabs auch Abstecher nach Fortran, Pascal usw, aber das war alles halbherzig). Danach kam Assembler und dann schon 'C'.

'C' kam mir wegen meiner hardwarenahen Denkweise sehr entgegen. Wenn ich heute Kleinst-Controller in 'C' programmiere, dann ist das so wie damals, als die PCs noch 4,7 MHz hatten.... Da wird der Kompiler-Output per Assembler auf Effizienz überwacht.

So nach und nach kamen dann die auf 'C' basierenden Erweiterungen und Dialekte. C++, C#, Java, php usw. usw...

Aber bis heute bin ich mir nicht zu fein, Fehler in tief verschachtelten Schleifen mit einem "goto end" zu behandeln.... , was stets reflexartige Schreikrämpfe bei den von-der-Uni-kommenden auslöst.

In mir steckt also noch ein kleines Stück Rest-Basic.

[alfsch]

klar, ist in C genauso....was du brauchst, ist die win-api referenz...
da stehen auch die Strukturen usw drin, die das System erwartet
zb hier gibbet dat...(microsaft laden hat selbst keinen (!!!!!) download mehr ..den ich auf die schnelle gefunden hätte)
http://www.codingcrew.de/programmierung/win32hlp.php

[Rumgucker]

Sag mal alfsch.....

...warum machst Du eigentlich das Projekt nicht weiter? Wenn Du mit eigener Software wiedergeben und aufnehmen kannst, dann ist doch schon mal fast alles klar. Außerdem kannst Du mit dem Tool mehr anfangen als ich das könnte.

[alfsch]

...weil ich
- zz einfach keine Zeit dazu habe
- am tieferen Sinn zweifle (*)
- eine Korrektur "live" und nicht mit umstandskram für eine einzelne Datei will (---wenn überhaupt )
- bislang kein sonderliches Interesse an irgendwelchen "Korrekturen" am Sound hatte - es sollte ohne jede Korrektur "passend" klingen

(*) die Genauigkeit der Korrektur kommt direkt vom Mikro...auch dessen Rauschen ; somit kann die "perfekt korrigierte" Datei maximal die Qualität und Rauschabstand des Mikro-sognals haben, was mir definitiv zu viel rauscht (und super-low-noise Mikros, die auch noch perfekt für Audio sind, sind extrem teuer )

[Rumgucker]

Und trotz dieser Zweifel und Bedenken gehörst Du zu denen, der hier bisher am massivsten mitgemacht haben.....

...das gibt mir sehr zu denken.

[alfsch]

na, sinnvoll oder nicht - interessieren tuts mich trotzdem

und bzgl programmieren...wenn ich dazu komme, dann wird das Messprogramm erstmal weiter gemacht; das ist leider nicht ganz sooo einfach, da ich ne etwas komplexe Methode verwenden will: das Signal ist ein Sinus-sweep, allerdings extrem "kurz", nur zb 1 sec lang; der wird dann in einen Impuls umgerechnet (Kreuzkorrelation) und davon FFT spektrum berechnet; cool daran ist: man kann damit Frequenzgang, Klirrfaktor und Ein-Ausschwingverhalten in einem Rutsch messen

[Rumgucker]

Ich leg das Projekt vorerst auf Eis...

1. ich mach gerne Projekte, bei denen ich alle Parameter in der Hand halte. Wo ich also selbst den Erfolg überprüfen kann. Das ist hier nicht der Fall. Ich muss abwarten, bis Ihr mir was gebt oder mal was anhört. Wie schleppend das bisher lief, sieht ja jeder selbst.

2. Nicht nur die Mitarbeit, auch das Interesse hier im Forum ist erbärmlich. Und das Verständnis war auch nicht so doll. Auch meine Werbetrommel in unserer Zeitung hat für mich keine weitere Motivation ergeben.

3. Ich müsste mich auf meine alten Tage noch in die Soundkartenprogrammierung per highlevel-API einarbeiten - weder Soundkarte noch derart "oberflächliche" Programme sind meine Welt.

4. Letztlich interessiert mich das Programm nicht, weil bei mir Musik nur schön laut sein muss.


Daher hier die bisher 157 C-Zeilen

https://stromrichter.org/d-amp/content/i...isator.cpp

Wenn man die Source in der VC++-Ide einbindet, dann erscheinen die Kommentare auch alle ausgerichtet exakt untereinander.

---------

Ich mach nun wieder vorzugsweise Projekte, von denen ich direkten Nutzen hab.

[Onkel_S]

Dass die erzeugte Datei nicht besser als das Mik sein kann, ist wohl wirklich ein Problem.

Schade dass das Projekt hier einfriert

...wenn ich doch nur nicht mit C++ auf Kriegsfuß wäre.

[Rumgucker]

Mach doch Basic....

----------

Ich denke, dass ein Mikro weit besser ist als ein Lautsprecher.

[Onkel_S]

Aber ein 50ct Elektret-Mik rauscht nun mal...

Ich weiß was man für einen Aufwand betreiben muss, damit man im Tonstudio gute Aufnahmen hin bekommt. Teure Technik, richtige Bedienung. Schon allein die Position des Mics kann ein Instrument gut oder beschissen klingen lassen. Das ist teilweise eine Sache von cm und wenigen Grad. Die falsche Mikposition und Charakteristik würde dem Egalisator falschen Input geben.
Rein vom messtechnischen Aspekt sind wohl auch die meisten Audiophilen nicht in der Lage...
Dennoch gibts genug Audio-Techniker, die das Programm auch anwenden könnten.

Mal sehen was wird.

[Rumgucker]

Nun haben wir doch alle den Unterschied vom Original zum Mikrosignal hier gesehen. Die Unterschiede waren enorm und mit dem bloßen Auge zu sehen.

Warum wollen wir jetzt ein Problem herbeireden, was weder zu sehen noch zu hören war?

Warum über 1% reden, wenn 99% das eigentliche Problem ist?

[alfsch]

Zitat:Original geschrieben von Rumgucker

Mach doch Basic....

----------

Ich denke, dass ein Mikro weit besser ist als ein Lautsprecher.

jein....bzgl einiger Werte, zb Klirr oder Frequ-linearität kann ein Mikro sehr gut gebaut werden, indem man zb eine Folie sehr dünn und sehr klein macht ....der Haken ist dann nur das Rauschen, da die Kapazität dieses Teils dann eben auch sehr klein wird und das "Rauschen" jedes einzelnen Elektrons irgendwann stört....die Methoden , das zu umgehen bzw zu verbessern, sind komplex: zb kann man einen Oszillator im UKW-bereich mit der Mikro-folien-kapazität modulieren und dann demodulieren um an das Audiosignal zu kommen.
das bringt eine hohe Dynamik...aber eben auch in etwa "nur" soviel , wie ein guter UKW Radio.
somit gibts kein Mikro , und schon gar kein bezahlbares, das auch nur annähernd den für "Hi-end" nötigen Rauschabstand liefert --- thats live