Toni DTMF

Ciao a tutti, apro questa nuova discussione, su un progetto di anni fa che vorrei riprendere.
I toni DTMF (https://it.wikipedia.org/wiki/Dual-tone_multi-frequency),
sono i classici toni delle tastiere dei telefoni.
Come si vede dal link, ogni singolo tasto è la somma (mix) di 2 frequenze.
E la frequenza alta ha intensità leggermente maggiore se non erro.
Il progetto era: in base alla registrazione estrarre e stampare i relativi numeri.
La bozza del progetto io l'avevo fatta in C, ma le idee sono generali.
Il problema dove sta?
Allora, io avevo pensato inizialmente di fare una registrazione separata, e salvare come file wave.
Gli altri file, mp3 ecc, hanno algoritmi di compressione che non conosco e che complicano la faccenda.
Registro perchè un'acquisizione direttamente da scheda audio in C non la so fare.
O meglio sono riuscito, ma non ho molta dimestichezza.
Quindi un passo alla volta: registro.
Una volta fatta la registrazione, potrei da programma andare a leggere i dati che compongono il suono,
e leggere il contenuto in modo binario.
Quindi la cosa più logica sarebbe fare un FFT che mi estrae le frequenze, e da li compararle, visto
che so a priori freq x=tasto Y.
Per la FFT in C c'è la libreria FFT3, velocissima, quindi non sarebbe un problema, ma non precisa al singolo Hz, se
non erro.
Oppure mi ero scritto una mia routine di DFT (è postata anche qui sul forum), estremamente lenta in confronto, ma precisa.
Almeno, se non ricordo male.
Però...c'è un però.
Al di la dei problemi che incontrerò, se non erro c'erano grane che ora non ricordo, la cosa peggiore è:
con la FFT io perdo la componente tempo.
Sei io digito 1,2,3 potrei anche estrarli, ma non saprei più l'ordine.
La FFT di una canzone a velocità normale, è uguale a un FFT della stessa, ma rallentata.
Mi estrae solo le frequenze e mi indica l'intensità.
Poi, non vorrei dire vaccate, sono cose complicate, magari non lo so io.
Quindi, consigli?
Bisognerebbe credo acquisire in modo interattivo: appena arriva un suono, elabora, e stampa, poi ascolta di nuovo.
Ma così facendo ho paura che dovrei usare processi o thread, che non so usare il C. Mi sono sempre
ripromesso di studiarli...ma...
e un loop, stile polling non so se funziona
Mha, se avete voglia, io sono qui

Si, la soluzione hardware mi era stata proposta anche altrove.
Sicuramente è più veloce e prestante, ma volevo provare via software.
Anche perchè di hardware non tocco nulla da anni e PORCO-DI-QUEL-MONDO mi stai facendo venire una
voglia matta di ritirare fuori tutto...vedremo.


In che senso ? Io potrei digitare 1,5,6 e registro in un file.
In quel file ci saranno le frequenze che compongono 1,5,6.
Se io faccio la fft, mi restituisce le frequenze, ma non l'ordine:
l'asse x è la frequenza, y l'intensità.
Quindi supponiamo che il 5 abbia frequenze più basse, io lo vedo prima dell'1 ma è stato digitato dopo.
Poi, ma ci devo ragionare, prendilo con le pinze.
Se noti due numeri diversi es:
3=697 hz e 1477 hz
6=770 hz e 1477 hz

supponiamo questi 2 numeri nella registrazione.
Se non ragiono male, facendo una fft troveri:
un picco da 697, uno da 770 e uno da 1477 quando invece sono 2 !!!
Ora non mi chiedere se quello da 1477 lo vedo doppio in intensità perchè si somma....non saprei
Anche io come te, anzi di più, non conosco bene la fft, solo e puro hobby.
Quindi devo trovare una strada alternativa.
Che potrebbe essere:
Registro e salvo come wave.
Parto con il mio programma in C, e inizio a leggere i dati.
Se l'intensità, è molto bassa, significa che non sta entrando nulla, e non memorizzo nell'array di float o duble
che servirà per la FFT.
Quando il volume è significativo, inizio a memorizzare. Quando torna a essere basso mi fermo.
Memorizzo dove sono arrivato a leggere nel file e mi fermo.
Analizzo l'array con fft e comparo, stampo.
Ora ricomincio da dove ero rimasto.
Potrebbe essere un modo.
Certo, tra un tono e l'atro non ci devono essere disturbi, altrimenti il metodo viene ingannato.
C'è poi la grana: ok, ma volume basso non memorizzo.
Ma quanto basso ? E se faccio una registrazione successiva e i volumi sono differenti ?
lo standard di prima non mi va più bene.
Si potrebbe ovviare normalizzando sempre allo stesso livello.
Buttata li: potrei cercare il volume massimo nel file e da li "traslare" il tutto in proporzione a un livello scelto
a priori.
Come sai, anche dietro banalità ci sono un sacco di cose da risolvere.
Vale la pena via software? Decisamente no.
Ma a volte sono sfide. Se non ci lavori te lo puoi permettere.
Che ne pensi dei ragionamenti, ti sembrano validi/fattibili?

E' vero Ele, se fai la trasformazione inversa recuperi il tempo. Devo ripassare un po'.
Si l'idea e' piu' o meno quella, dividere il file

Grazie GWF, devo mettere insieme un po' le idee, poi magari ci provo.
Una bozza ce l'avevo già, ma a sto punto meglio se ricomincio daccapo.
Mi ha messo la pulce nell'orecchio Elemento 38: in effetti quando fai una fft, puoi sempre fare un reverse, e quindi il tempo
non va perso.
Ma io non so perchè mi pare di ricordare di avere avuto questo problema.
C'è da dire che la FFT è complessa e magari io la usavo in modo errato, ma per i miei scopi andava bene.
Per esempio metà dei dati se non ricordo male sono uguali alla prima metà, quindi io non li usavo...bhò...
Bisogna leggere un po' è fare prove

Può essere, ma la mia piccola esperienza m'insegna che le insidie sono sempre di più di quello che ti aspetti.
Sia dal punto di vista teorico, sia implementativo (il C poi non aiuta).


Un file direi che per iniziare è meglio. Avevo provato a studiare Alsa ma ci ho rinunciato. Riesco a importare direttamente
dalla scheda con portaudio, ma l'ho usato solo poche volte.
File è meglio per ora.
Direi, wave, senza complicarci la vita: vado al 44° byte (se ricordo bene) e in modalità binaria leggo.


Ok, qui un piccolo problema (se ricordo bene), tu sei fresco di matematica e mi puoi confermare smentire:
Supponi un wave a 44100 Hz di sample rate, quindi 44100/2=22050 massima frequenza registrabile, secondo il teorema
di...di...insomma un tizio forse Nyquist, non ricordo.
FFT di 1024 punti, quindi avrò una risoluzione di 22050/ (1024/2)= 43 hz
E quindi nel cercare i picchi dovrò tenere conto di queste tolleranze.
La DFT invece che mi ero scritto (non ho inventato nulla eh!!! ) è molto lenta ma precisa al singolo Hz.


Anche qui, sembra facile, ma non credo sia così semplice...ma non so, bisogna provare.
Una sorta di "normalizzazione" secondo me va fatta. A meno che non sia ha l'accortezza di registrare sempre nello stesso
modo.

Appena ho tempo mi metto in ballo e faccio prove con Audacity, dove posso generare frequenze, anche toni dtmf ecc..
e poi ci sarebbe da ripassare la fft, almeno il grosso.
Se non erro però il discorso della risoluzione degli hz in base alla finestra è quello,
Per ridurre devi aumentare i punti della fft, con conseguente aggravio prestazionale.
Ma quello non credo sia un problema. La fftw3 è velocissima.

Certo che via hardwre sarebbe una figata da provare....
M'interessa il tuo\vostro parere su:

In che senso ?
Dai, di la tua, non e' vietato parlare anche di hardware.

Ok, forse si hai ragione, meglio non far casino...e sai benissimo che io di natura...diciamo che ci metto (in buona fede) meno di zero ad andare OT !!
Appena posso faccio le prime prove.

Ok, sarei curioso di sapere un po' il principio di funzionamento di integrati simili. Presumo abbiano filtri "strettissimi" per poi elaborare il tutto. Ma mi fermo.