You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the pitch engine processes the incoming audio stream in consecutive, separate buffers. There's no overlap in the data between buffers. So for a 44.1kHz input stream and a standard 4096 sample size, the engine returns about ten results per second to the delegate.
I'd like to see support for buffers with overlapping samples. For example, I could specify a sample size of 4096 but an overlap of 2048 samples. Then the pitch engine would pass overlapping windows of audio data to the estimator. In this example, the estimator would end up doing twice as much work, but it would return twice as many results per second with full accuracy.
A basic implementation of this could be done entirely in the existing PitchEngine class, without altering the interface used by the Estimator. A more advanced implementation could be done down the road using algorithms better suited for real-time audio processing (i.e. adding incremental data without reprocessing the whole window).
Would this kind of feature be welcomed in this project? If so, I could write this real quick and submit a pull request.
The text was updated successfully, but these errors were encountered:
I'm loving Beethoven. Great library.
Currently, the pitch engine processes the incoming audio stream in consecutive, separate buffers. There's no overlap in the data between buffers. So for a 44.1kHz input stream and a standard 4096 sample size, the engine returns about ten results per second to the delegate.
I'd like to see support for buffers with overlapping samples. For example, I could specify a sample size of 4096 but an overlap of 2048 samples. Then the pitch engine would pass overlapping windows of audio data to the estimator. In this example, the estimator would end up doing twice as much work, but it would return twice as many results per second with full accuracy.
A basic implementation of this could be done entirely in the existing PitchEngine class, without altering the interface used by the Estimator. A more advanced implementation could be done down the road using algorithms better suited for real-time audio processing (i.e. adding incremental data without reprocessing the whole window).
Would this kind of feature be welcomed in this project? If so, I could write this real quick and submit a pull request.
The text was updated successfully, but these errors were encountered: