audio signal-processing fft pitch pitch-tracking

audio - Detección de tono en tiempo real



signal-processing fft (10)

Estoy tratando de hacer la detección de tono en tiempo real de los usuarios cantando, pero me estoy enfrentando a muchos problemas. He intentado muchos métodos, incluyendo FFT ( Problema de FFT (Devuelve resultados aleatorios) ) y autocorrelación (la detección de tono de autocorrelación arroja resultados aleatorios con la entrada de micrófono ), pero parece que no puedo obtener ningún método para dar un buen resultado. ¿Alguien puede sugerir un método para el seguimiento de tono en tiempo real o cómo mejorar un método que ya tengo? Parece que no puedo encontrar ningún buen método C / C ++ para la detección de tono en tiempo real.

Gracias,

Niall.

Editar: Solo para observar, he comprobado que los datos de entrada del micrófono son correctos, y que cuando se utiliza una onda sinusoidal los resultados son más o menos el tono correcto.

Editar: Lo siento, pero es tarde, pero de momento estoy visualizando la autocolleración sacando los valores de la matriz de resultados, y cada índice, y graficando el índice en el eje X y el valor en el eje Y (ambos están divididos por 100000 o algo así, y estoy usando OpenGL), conectar los datos en un host VST y usar complementos VST no es una opción para mí. Por el momento, solo parece algunos puntos aleatorios. ¿Lo estoy haciendo correctamente o puede indicarme algún código para hacerlo o ayudarme a entender cómo visualizar los datos de audio sin procesar y los datos de autocorrelación?

¿Puedes adaptar algo desde sintonizadores de instrumento? Mi sintonizador de guitarra deliciosamente compacto es capaz de detectar el tono de las cuerdas bastante bien. Veo esta referencia a un afinador de pianos que explica un algoritmo hasta cierto punto.

Aquí está el código fuente de C ++ para un algoritmo inusual de dos etapas que ideé y que puede hacer detección de tono en tiempo real en archivos MP3 polifónicos mientras se reproduce en Windows. Esta aplicación gratuita ( PitchScope Player , disponible en la web) se utiliza con frecuencia para detectar las notas de una guitarra o un solo de saxofón en una grabación de MP3. El algoritmo está diseñado para detectar el tono más dominante (una nota musical) en cualquier momento dado dentro de un archivo de música MP3. Los inicios de notas se infieren con precisión mediante un cambio significativo en el tono más dominante (una nota musical) en cualquier momento dado durante la grabación de MP3.

Cuando se presiona una sola tecla en un piano, lo que escuchamos no es solo una frecuencia de vibración de sonido, sino una combinación de múltiples vibraciones de sonido que se producen en diferentes frecuencias relacionadas matemáticamente. Los elementos de este compuesto de vibraciones a diferentes frecuencias se conocen como armónicos o parciales. Por ejemplo, si presionamos la tecla del Medio C en el piano, las frecuencias individuales de los armónicos del compuesto comenzarán en 261.6 Hz como la frecuencia fundamental, 523 Hz sería el 2. ° armónico, 785 Hz sería el 3. ° armónico, 1046 Hz ser el 4 ° armónico, etc. Los armónicos posteriores son múltiplos enteros de la frecuencia fundamental, 261.6 Hz (ej: 2 x 261.6 = 523, 3 x 261.6 = 785, 4 x 261.6 = 1046). Enlazado en la parte inferior, hay una instantánea de los armónicos reales que se producen durante una grabación polifónica MP3 de un solo de guitarra.

En lugar de una FFT, utilizo una transformada DFT modificada, con espaciado de frecuencia logarítmica, para detectar primero estos armónicos posibles buscando frecuencias con niveles máximos (vea el diagrama a continuación). Debido a la forma en que reúno datos para mi Log DFT modificado, NO tengo que aplicar una función de ventana a la señal, ni agregar y solapar. Y he creado el DFT para que sus canales de frecuencia estén ubicados logarítmicamente para alinearse directamente con las frecuencias donde los armónicos son creados por las notas en una guitarra, saxofón, etc.

Ahora que estoy jubilado, he decidido liberar el código fuente de mi motor de detección de tono dentro de una aplicación de demostración gratuita llamada PitchScope Player . PitchScope Player está disponible en la web, y puede descargar el ejecutable para Windows para ver mi algoritmo en funcionamiento en un archivo mp3 de su elección. El siguiente enlace a GitHub.com lo llevará a mi código fuente completo donde puede ver cómo detecto los armónicos con una transformada DAR logarítmica personalizada, y luego buscar parciales (armónicos) cuyas frecuencias satisfacen la relación entera correcta que define un '' tono''.

Mi algoritmo de detección de tono es en realidad un proceso de dos etapas: a) Primero se detecta ScalePitch (''ScalePitch'' tiene 12 valores de tono posibles: {E, F, F #, G, G #, A, A #, B, C, C #, D, D #}) b) y después de que se determina ScalePitch, la Octava se calcula examinando todos los armónicos para las 4 posibles notas de Octava-Candidato. El algoritmo está diseñado para detectar el tono más dominante (una nota musical) en cualquier momento dado dentro de un archivo polifónico MP3. Eso usualmente corresponde a las notas de un solo instrumental. Aquellos interesados ​​en el código fuente de C ++ para mi algoritmo de detección de tono de dos etapas pueden querer comenzar en la función Estimate_ScalePitch () dentro del archivo SPitchCalc.cpp en GitHub.com. https://github.com/CreativeDetectors/PitchScope_Player

A continuación se muestra la imagen de un Logarithmic DFT (creado por mi software C ++) durante 3 segundos de un solo de guitarra en una grabación polifónica mp3. Muestra cómo aparecen los armónicos para notas individuales en una guitarra, mientras se reproduce un solo. Para cada nota de este Logarithmic DFT podemos ver sus múltiples armónicos que se extienden verticalmente, ya que cada armónico tendrá el mismo ancho de tiempo. Después de que se determina la octava de la nota, entonces sabemos la frecuencia de lo fundamental.

Consulte aubio y la biblioteca de código abierto que incluye varios métodos avanzados para el seguimiento del tono.

Dar un paso atrás ... Para que esto funcione, DEBE encontrar una manera de trazar los pasos intermedios de este proceso. Lo que estás tratando de hacer no es particularmente difícil, pero es propenso a errores e inquietante. Recorte, ventanas, cableado incorrecto, aliasing, desviaciones de DC, lectura de los canales incorrectos, el extraño eje de frecuencia FFT, desajustes de impedancia, errores de tamaño de fotograma ... quién sabe. Pero si puede trazar los datos brutos y luego trazar la FFT, todo se aclarará.

Echa un vistazo a esta aplicación de muestra:

http://www.codeproject.com/KB/audio-video/SoundCatcher.aspx

Me doy cuenta de que la aplicación está en C # y necesitas C ++, y me doy cuenta de que esto es .Net / Windows y estás en una Mac ... Pero pensé que su implementación de FFT podría ser un punto de referencia de partida. Intenta comparar tu implementación de FFT con la suya. (La suya es la versión iterativa y amplia de la FFT de Cooley-Tukey). ¿Son similares?

Además, el comportamiento "aleatorio" que describes puede deberse a que estás capturando datos devueltos por tu tarjeta de sonido directamente sin ensamblar correctamente los valores de la matriz de bytes. ¿Le pidió a su tarjeta de sonido que muestre valores de 16 bits y luego le dio una matriz de bytes para almacenar los valores? Si es así, recuerde que dos bytes consecutivos en la matriz devuelta constituyen una muestra de audio de 16 bits.

El código de Java para un detector real en tiempo real está disponible en http://code.google.com/p/freqazoid/ .

Funciona bastante bien en cualquier computadora que ejecute Java en tiempo posterior a 2008. El proyecto se ha eliminado y podría ser recogido por cualquier parte interesada. Contáctame si quieres más detalles.

Encontré varias implementaciones de código abierto de seguimiento de tono en tiempo real

También hay algunos seguidores de tono que quizás no estén diseñados para tiempo real, pero pueden ser útiles de esa forma por lo que sé, y también podrían ser útiles como referencia para comparar su rastreador en tiempo real con:

Sé que esta respuesta no hará felices a todos, pero aquí va.

Esto es difícil, muy difícil. Primero ve a leer todos los tutoriales que puedas encontrar en FFT, Autocorrelación, Wavelets. Aunque todavía estoy luchando con DSP obtuve algunas ideas de lo siguiente.

https://www.coursera.org/course/audio el curso no se está ejecutando en este momento, pero los videos todavía están disponibles.

http://miracle.otago.ac.nz/tartini/papers/Philip_McLeod_PhD.pdf tesis sobre el desarrollo de un algoritmo de reconocimiento de tono.

http://dsp.stackexchange.com un sitio completo dedicado al procesamiento digital de señales.

Si, como yo, no hiciste suficientes operaciones matemáticas para seguir completamente los tutoriales, no te rindas ya que algunos de los diagramas y ejemplos aún me ayudaron a comprender lo que estaba sucediendo.

Lo siguiente son los datos de prueba y las pruebas. Escríbase una biblioteca que genere archivos de prueba para usar al verificar sus algoritmos.

1) Un generador de onda sinusoidal puro súper simple. Digamos que está buscando escribir YAT (Yet Another Tuner) y luego usa su generador de seno para crear una serie de archivos alrededor de 440Hz digamos de 420-460Hz en incrementos variables y vea qué tan sensible y preciso es su código. ¿Se puede resolver a 5Hz, 1Hz, aún más?

2) Luego actualice su generador de onda sinusoidal para que agregue una serie de armónicos más débiles a la señal.

3) Lo siguiente son variaciones del mundo real en armónicos. Entonces, mientras que para la mayoría de los instrumentos de cuerda verá una serie de armónicos como múltiplos simples de la frecuencia fundamental F0, para instrumentos como clarinetes y flautas debido a la forma en que se comporta el aire en la cámara, los armónicos pares faltarán o serán muy débiles. Y para algunos instrumentos falta F0, pero se puede determinar a partir de la distribución de los otros armónicos. F0 es lo que el oído humano percibe como tono.

4) Dispara una cierta distorsión deliberada al subir y bajar las frecuencias armónicas pico de forma irregular

El punto es que si está creando archivos con resultados conocidos, entonces es más fácil verificar que lo que está construyendo realmente funciona, por supuesto, hay errores.

También hay una serie de "bibliotecas" que contienen muestras de sonido. https://freesound.org de la serie de Coursera mencionada anteriormente. http://theremin.music.uiowa.edu/MIS.html

Luego, tenga en cuenta que su micrófono no es perfecto y, a menos que haya gastado miles de dólares, tendrá un rango de respuesta de frecuencia bastante variable. En particular, si está trabajando con notas bajas, entonces los micrófonos más baratos, lea los incorporados en su PC o teléfono, tienen un rolloff significativo que comienza alrededor de 80-100Hz. Para los externos, razonablemente buenos, puede bajar a 30-40Hz. Ve a buscar los datos en tu micrófono.

También puede verificar qué sucede tocando el tono a través de los altavoces y luego grabando con su micrófono favorito. Pero, por supuesto, ahora estamos hablando de 2 conjuntos de curvas de respuesta de frecuencia.

En lo que respecta al rendimiento, hay una serie de bibliotecas disponibles de forma gratuita, aunque tenga en cuenta los distintos modelos de licencia.

Sobre todo, no te rindas después de tus primeros intentos. La mejor de las suertes.

Tuve un problema similar con la entrada de micrófono en un proyecto que hice hace unos años, resultó ser un offset de CC.

Asegúrese de eliminar cualquier sesgo antes de intentar FFT o cualquier otro método que esté utilizando.

También es posible que te encuentres con problemas de espacio libre o recorte.

Los gráficos son la mejor manera de diagnosticar la mayoría de los problemas con el audio.