|Home||Papers||Projects||Code Fragments||Dissertations||Presentations||Posters||Reports||Proposals||Lectures given||Course notes|
BPM Measurement of Digital Audio by Means of Beat Graphs & Ray Shooting
Werner Van Belle1* - firstname.lastname@example.org, email@example.com
Abstract : In this paper we present a) a novel audio visualization technique, called beat-graphs and b) a fully automatic algorithm to measure the mean tempo of a song with a very high accuracy. The algorithm itself is an easy implementable offline search algorithm that looks for the tempo that best describes the song. For every investigated tempo, it steps through the song and compares the similarity of consecutive pieces of information (bass drum, a hi-hat, ...). Its accuracy is two times higher than other fully automatic techniques, including Fourier analysis, envelope-spectrum analysis and autocorrelation.
bpmdj meta data extraction tempo measurement beats per minute BPM measurement
Searching: Selective Descent
Comparing against related work
Fourier Analysis of the Energy Envelope
Results & Discussion
Key + Period = Tempo = Key/Period
Full Result Listing
Automatically measuring the tempo of a digital soundtrack is crucial for DJ-programs such as BpmDJ [1, 2], and other similar software. The ability to mix two (or more) pieces of music, depends almost entirely on the availability of correct tempo information. All too often this information must be manually supplied by the DJ. This results in inaccurate tempo descriptions, which are useless from a programming point of view . Therefore we will investigate a technique to measure the tempo of a soundtrack accurately and automatically. In the upcoming discussion we assume that the audio fragments that need to be mixed have a fixed1 and initially unknown tempo.
The tempo of a soundtrack is immediately related to the length of a repetitive rhythm pattern encoded within the audio-fragment. This rhythm pattern itself can be virtually anything: a 4/4 dance rhythm, a 3/4 waltz, a tango, salsa or anything else. We assume that we have no information whatsoever about this rhythm pattern.
This paper is structured in four parts. First we elaborate on the required tempo accuracy. Second, we explain our beat graph visualization technique. This technique flows naturally into the the ray shooting algorithm, which is the third part. And last, we elaborate on our experiments and compare our technique with existing techniques.
Without accurate tempo information two songs will drift out of synchronization very quickly. This often results in a mix that degrades to chaos, which is not what we want. Therefore we must ask ourselves how accurately the tempo of a song should be measure to be useful. To express the required accuracy, we will calculate the maximum error on the tempo measurement to keep the synchronization drift after a certain timespan below a certain value.
We assume that the tempo of the song is measured with an error . If the exact tempo of the song is BPM then the measurement will report BPM. Such a wrong measurement leads to a drift after a certain timespan . The timespan we consider, is the time needed by the DJ to mix the songs. Typically this can be 30'', 60'' or even up to 2 minutes if (s)he wants to alternate between different songs. We will express the drift in beats (at the given tempo), not in seconds. We chose not to use absolute time values because slow songs don't suffer as much from the same absolute drift as fast songs. E.g, a drift of 25 ms is barely noticeable in slow songs (E.g, 70 BPM), while such a drift is very disturbing for fast songs (E.g, 145 BPM). Therefore, we consider a maximum drift of beat, with being the note-divisor. For instance, we will calculate the required accuracy to keep the drift below , and beat. Given the exact tempo (in BPM) and the measurement error (in BPM), we can now calculate the drift (in beats) after timespan (in seconds).
To do so, we must first know how many beats are contained within the timespan . Based on the standard relation between period and frequency2, this is beats. Because the tempo is measured with an accuracy of BPM, we get a drift (expressed in beats) of . To keep this drift below beat, we must keep . Because , we obtain a required accuracy of
Equation 1 describes how accurately one song should be measured to have a maximum possible drift of beats after a time of seconds. In practice, at least two songs are needed to create a mix. If all involved songs are measured with the same accuracy , then the maximum drift after seconds will be the sum of the maximum drifts of all involved songs. From this, it becomes clear that we need to divide the required accuracy by the number of songs. Table 2 gives an overview of the required accuracies. As can be seen, an accuracy of 0.0313 BPM is essential, while an accuracy of 0.0156 BPM is comfortable.
To explain our ray shooting technique we will first introduce the concept of beat-graphs. Not only can they help in manually measuring the tempo of a soundtrack, they also naturally extend to our ray-shooting technique.
|Figure 1:Beat graphs of two songs.|
A beat graph visualizes an audio-stream (denoted as a series of samples ) under a certain period . In the remainder of the text we will assume that we are investigating an audio-fragment . This fragment has a length of samples and is sampled at a sampling rate . If not specified will be considered to be a standard of 44100 Hz. Given this notation, the beat graph visualizes If we have an audio fragment, denoted , with a length of samples, It visualizes the function
Horizontally, the measures are enumerated, while vertically the content of one such a measure is visualized. The color of a pixel at position is given by the absolute strength of the signal at time step . The value is the period of the rhythm pattern. This typically contains 4 beats in a 4/4 key.
Picture 1 shows two beat graphs of Tandu and Posford [4, 5]. Reading a beat graph can best be done from top to bottom and left to right. For instance in the song Alien Pump  we see 4 distinct horizontal lines (numbers 1, 2, 3 and 4). These are the the 'beats' of the song. The top line covers all the beats on the first note in every measure, the second horizontal line covers all the beats at the second note within a measure and so on... The vertical white strokes that break the horizontal lines (C, D and E) are breaks within the music: passages without bass drum or another notable signal. Because the lines are distinctively horizontal we know that the period is correct. If the lines in the beat graph are slanted such as in Lsd then the period (and thus the tempo) is slightly incorrect. In this case, the line is slanted upwards which means that the period is too short (the beat on the next vertical line comes before the beat on the current line), and this means that the tempo is a bit too high. By looking at the direction of the lines in a beat graph we can relate the actual tempo to the visualized tempo.
|Figure 2: Beat graphs of two songs.|
The beat graph not necessarily displays only straight lines. Two examples of this are given in figure 2. The first example is the song X-Files . In the beginning the tempo line bends upward indicating that the song is brought down from a higher tempo. After a break the tempo remains constant. Another example is the song Anniversary Waltz  in which we clearly see a drummer who drifts around a target tempo.
Our visualization technique of beat graphs offers some important advantages. First, the visualization function is very easy to implement and can be calculated quickly. This is in stark contrast with voice prints, which require extensive mathematical analysis and offer no immediately useful tempo information. Secondly, the beat graph contains rhythm information. From the viewpoint of the DJ, all the necessary information is present. The temporal organization can be recognized by looking at the picture. E.g, we can easily see how the songs Alien Pump  contains beats at notes 1, 2, 3, 4 and 4 (position A in the picture). After a while the extra beat at the end of a measure is shifted forward in time by half a measure (position B). Similarly, breaks and tempo changes can be observed (C, D and E). Third, as a DJ-tool it offers a visualization that can be used to align the tempo immediately. E.g, by drawing a line on the beat-graph such as done in Lsd , it is possible to recalculate the graph with an adjusted period. Not only will this introduce accurate tempo information, it also introduces the information necessary to find the start of a measure. This makes it easy to accurately and quickly place cue-points.
We will now further investigate how we can fully automatically line up the beat graph. If we are able to do so then we are able to calculate the tempo of a song automatically.
Beat graphs give us the possibility to visualize the tempo information within a song. We will now use this to search for the best possible visualization of the beat graph. An optimal visualization will give rise to as much 'horizontality' as possible. 'Horizontality' is measured by comparing every vertical slice (every measure) of the beat graph with the previous slice (the previous measure). Through accumulation of the differences between the consecutive slices we obtain a number that is large when little horizontality is present and small when a lot of horizontality is present. Formally, we measure
The use of the absolute value in the above equation is necessary to accumulate the errors. If this would not be present then a mismatch between two measures at position could be compensated for by a good match between two measures at another position .
Equation 2 can be written more simply by expanding :
The problem we face now, is to find the period for which is the smallest. must be located within a certain range, for instance between the corresponding periods of 80 BPM and 160 BPM. Once this period is found, we can convert it back to its tempo. Converting a period to BPM is done as follows.
In the above conversion rules, denotes the number of beats within the rhythm pattern. This typically depends on the key of the song. For now, we will assume that every measure contains 4 beats, later on we will come back to this and explain how this number can also be measured automatically. Using the above equation we can define the period range in which we are looking for the best match. We will denoted this range with the smallest period (thus the highest tempo) and is the highest period (and thus the lowest frequency). Given these two boundaries, we can calculate the period of a song as follows
A possible optimization to this search process is the introduction of clipping values: When, during calculation of one of the rays, the current ray accumulates an error larger than the smallest ray until now (the clipping value) it can simply stops and returns the clipping value:
Because this ray function is limited to the computational complexity of the last best match, its calculation time can, as the number of scans increase, only decrease. The search algorithm can then be written down as
The time needed to calculate the value of is . Because the period is often neglectable small in comparison to the entire length of a song, we omit it. Hence, takes time to finish. To find the best match in a certain tempo range by doing a brute force search we need to shoot rays. We will denote the size of this window . The resulting time estimate is accordingly . This performance estimate is linear which might look appealing, however, the size of the window is typically a very large constant, so this performance estimate should be handled with care. Nevertheless, the real strength of our approach comes from its extremely high accuracy and its modular nature.
Our algorithm can verify any period above 0 and below . This means that it can distinguish which one of two periods or period is the best. Therefore, we will calculate the accuracy by measuring the smallest distinguishable tempo. Given a certain tempo, we will convert it to its period and then assume that we have measured the period wrongly with the least possible error of 1 sample. The two resulting periods are converted back to BPM's and the differences between these two equals the theoretical accuracy. Suppose the tempo of the song is , then the period of this frequency is . The closest distinguishable next period is . After converting these two periods back to their tempos we get and thus an accuracy of . Expansion of this expression results in
Table 3 presents an overview of the accuracies we might obtain with this technique. As can be seen, even the least accurate measurable tempo (170 BPM) can be distinguished with an accuracy of 0.00273, which is still 11 times more accurate than the required accuracy of 0.0313. For lower frequencies this even increases to 67.4 times better than the required accuracy ! It should be noted here that this is a theoretical accuracy. Later on we will experimentally validate the practical accuracy.
The algorithm as presented allows to verify the presence of one frequency in . This opens the possibilities to parallelize the algorithm easily but also the possibility to actively search for matching frequencies while neglecting large parts of the search space. This of course requires a suitable search algorithm. In the following section we will shed light on one search approach that has proven to be very fast and still highly accurate.
As explained in the previous section, verifying every possible frequency by doing a brute force search would take too much time. Nevertheless, the algorithm as presented here, allows the verification of single frequencies very accurately and quickly. This has lead to an algorithm that first does a quick scan of the entire frequency spectrum and then selects the most important peaks to investigate in further detail.
To skip large chunks of the search space, we use an incremental approach. First, the algorithm does a coarse grained scan that takes into account 'energy' blocks of information (let's say with a block size of ). From the obtained results, it will decide which areas are the most interesting to investigate in further detail. This is done by calculating the mean error of all measured positions. Everything below the mean error will be investigated in the next step. We repeat this process with a smaller block size of until the block size becomes 1.
The problem with this approach is that it might very well overlook steep dalls and consequently find and report a completely wrong period/tempo. To avoid this we will flatten the function by resampling the input data to match the required block size.
To avoid a strongly oscillating function, which would make a selective descent very difficult, we will, in every iteration step, resample the audio stream to the correct frequency. This resampling however is very delicate. Simply by taking the mean of the data within a block, we will throw away valuable information. In fact, we will throw everything away that cannot be represented at the given sampling rate. E.g, if we have a block size of 1024 then the final sampling rate will be 43 Hz. Such low sampling rates can only describe the absolute low frequencies up to 21.5 Hz . Please note here, that such a down sampling not only throws away harmonics (such as a down sampling from 44100 Hz to 22050 Hz would do), but actually throws away entire pieces of useful information (like for instance hi-hats). Such a sampling rate conversion is clearly not what we are looking for. Therefore we have invented the following resampling algorithm
With every step, the algorithm will first rescale the audio stream by shrinking every block of sample to 1 sample. This is done by taking the energy content of the block:
As the caution reader may observe, we do not take the square of the value as would be necessary to correctly describe the energy content of the block. The reason why we didn't is twofold. First because this approach is faster and keeps the values within a reasonable bit range, hence remains accurate. Second, because we are concerned with signals representing musical content and the spectrum of music already follows a power distribution.
With the knowledge how to resample the audio fragment and how to search for the most prominent frequency, we can now write down the algorithm in full detail. In the algorithm below is the number of beats that are supposed to be in one measure. and (see equation 4). The window size is given by . The resample function is described in equation 6 and the function is described in equation 5. is the number of requested iterations. The maximum block size will then be .
2. resample( , )
3. for(; ; )
4. ray(, , )
5. for(; ; )
6. resample( , )
7. for(; ; )
9. ray(,, )
10. for( , ; ; )
12. ray( , , )
Estimating the performance of this algorithm is easy but requires some explanation. Let us assume that we start with a block size of . This means that we will iterate steps.
The initial step, with a block size of will result in rays to be shot. The cost to shoot one ray depends on the audio size. After resampling this is .
The following steps, except for the last, are similar. However, here it becomes difficult to estimate how many rays that will be shot, because we take the mean error of the previous step and select only the region that lies below the mean error. How large this area is, is unknown. Therefore we will call the number of new rays divided by the number of old rays the rest-factor . After one step, we get rays; after two steps this is and by induction after steps the number of rays becomes . Every ray, after resampling to a block size of , takes time, hence the time estimation for every step is . We continue this process from until .
The last step () is similar, except that we can do the ray shooting it in half the expected time because we are looking for the minimum and no longer for the mean error. This results in
The resampling cost at every step is . After adding all steps together we obtain:
After some reductions, we obtain:
Depending on the factor of and we obtain different performance estimates. We have empirically measured the value of under a window of [80 BPM:160 BPM]. We started our algorithm at a block size of and have observed that the mean value of is 0.85. This results in an estimate of . In practice, from the possible 66150 rays to shoot we only needed to shoot 142,35 to obtain the best match. So, we only searched 0.20313 % of the search space before obtaining the correct answer. This is a speedup of about 246.18 times in comparison with the brute force search algorithm.
We have implemented this algorithm as a BPM counter for the DJ program BpmDj . The program can measure the tempo of .MP3 and .OGG files. It is written in C++ and runs under Linux. The program can be downloaded from http://bpmdj.sourceforge.net/. The parameters the algorithm currently uses are: , , . Of course these can be modified when necessary. The algorithm starts iterating at and stops at because a higher accuracy is simply not needed.
|Figure 3:Tempo scanning two songs.|
Figure 3 shows the output it produces for two songs. Every color presents the results of one scanning iteration. The first scan is colored green, the last scan is colored red. The horizontal colored lines represent the position of the mean values for that scan. As can be seen, by using the mean value, quickly large parts of the search space are omitted.
To compare the accuracy of our technique with other measurement techniques, we also inserted two well-known BPM-measurement techniques into BpmDj. The first technique does a Fourier analysis of the audio envelope in order to find the most prominent frequency. The second techniques calculates the power density spectrum of the audio sample, which happens to be the same as the autocorrelation function. Techniques that are not fully automatically have been omitted. Hence, we excluded techniques that make use of a database describing possible rythms . Below we briefly describe some other techniques.
Peak detectors make use of Fourier analysis or specially tuned digital filters to spike at the occurrence of bass drums (frequencies between 2 and 100 Hz), hi-hats (above 8000 Hz) or other repetitive sounds. By analyzing the distance between the different spikes, they might be able to obtain the tempo. The problem with such techniques is that they are inherent inaccurate, and not only requires detailed fine tuning of the filter-bank but afterwards still require a comprehension phase of the involved rhythm . Their inaccuracy comes from the problem that low frequencies (encoding a bass drum for instance) have a large period, which makes it difficult to position the sound accurately. In other words, the Fourier analysis will spike somewhere around the actual position of the beat, thereby making the algorithm inherent inaccurate. The second problem of peak detectors involves the difficulties of designing a set of peak-responses that will work for all songs. E.g, some songs have a hard and short bass-drum with a lot of body while other song have a muffled slowly decaying bass-drum. Tuning the algorithm such that it can detect correctly the important sounds in almost all songs can be difficult. Finally, the last problem of peak detectors is that they often have no notion of the involved rhythm. E.g, a song with a drum line with beats at position 1, 2, 3, 4 and are notoriously difficult to understand because the last spike at position will seriously lower the mean time between the different beats. This can be remedied through using a knowledge base of standard rhythms.
In comparison with peak detectors our technique is clearly superior because it is a) much easier to implement, b) does not require a comprehension phase and c) is much more accurate.
This technique obtains the energy envelope of the audio sample and will then transform it to its frequency representation. The most prominent frequency can be immediately related to the tempo of the audio fragment [13, 14]. From a performance point of view this techniques are much better than the algorithm we presented. Especially if one makes use of the Goertzel algorithm . The accuracy of these techniques can be theoretically as good as our technique, assuming that one takes a window-size that is large enough. E.g, to have an accuracy of 0.078 BPM at a sampling rate of 44100 Hz one needs at least a window size of , which is an audio-fragment of 12' 40''. When such a window-size is not available (because the audio-fragment is not as long), the envelope should be zero-padded up to the required length .
At first sight, our algorithm might seem similar to autocorrelation because we compare the song with itself at different distances. However, this is only a superficial similarity. To understand this we point out that autocorrelation for a discrete audio signal is defined as . As can be seen, the comparison between different slices is done by multiplying the different values. In our algorithm we only measure the distance between the absolute values, so there is no clear direct correspondence between ray shooting and autocorrelation. Nevertheless autocorrelation has been applied to obtain the mean tempo of an audio fragment. The computation of can be done using quickly using two Fourier transforms. The process takes 3 steps. First the audio-fragment is transformed to its frequency-domain, then every sample is replaced with its squared norm and finally a backward Fourier transform is done. Formally, .
The experiment consisted of a selection of 150 techno songs. The tempo of each song has been manually measured through aligning their beat graphs. All songs had a tempo between 80 BPM and 160 BPM. Of them 7 had a drifting tempo. In these songs we have manually selected the largest straight part (such as done for the song X-Files ). Afterwards, we have run the BPM counter on all the songs again. For every song the counter reported the measurements using different techniques and the time necessary to obtain this value. The machine on which we did the tests was a Dell Optiplex GX1, 600 MHz running Debian GNU/Linux. The counter has been compiled with the Gnu C Compiler version 3.3.2 with maximum optimization, but without machine specific instructions.
The song Tainted Love  (see picture 3) is interesting because it shows 4 distinct spikes in the ray-shoot analysis. Every spike is a multiple of each other. In fact, the spike is the actual tempo with a measured period of 4 beats, which is a correlation between beat 1 and beat 5. The spike occurs when the algorithm correlates between the 1st and the beat, hence calculates a tempo with measures of 5 beats, while it expects to find only 4 beats in a measure. This results in a tempo of 114.5. The spike is similar but now a correlation between the and the beat occurs. The first spike is a correlation between the beat and the beat. We have these distinct spikes because the song is relatively empty and monotone.
All techniques have a problem with estimating how many beats are located within one rhythmic pattern. When a tempo is reported that is a multiple of the required tempo we call it an harmonic.
The results of our experiment can be downloaded from http://bpmdj.sourceforge.net/bpmcompare.html or seen in the appendix.
As expected the results contained a number of wrongly reported errors due to harmonics. These have been detected and eliminated by simply multiplying the reported period by , or . The autocorrelation technique reported an harmonic tempo in 26% of the cases, the ray-shooting technique in 17 % and the Fourier analysis in 5 %. Clearly the Fourier analysis is superior with respect to the problem of harmonics.
However, with respect to the accuracy of the measurement, our ray-shooting technique is best. It measures the mean tempo with an accuracy of 0.0413. From which we can conclude that our algorithm has a practical accuracy of 0.0340 BPM, which is close to the required accuracy of 0.0313. The autocorrelation technique has an accuracy of 0.0759 BPM. The Fourier analysis has an accuracy of 0.0903 BPM. The latter is consistent with reported accuracies. If we look at the speed of our algorithm then it is clearly outperformed. Both the autocorrelation and Fourier analysis are between 2 and 4 time as fast as the autocorrelation technique.
Our ray shooting technique finds the period of an unknown repetitive rhythm pattern. As observed it might sometimes report an harmonic of the actual tempo. This happens because we have always assumed that every rhythm pattern contains 4 beats (see equation 4). In practice this is not always the case for two reasons.
First, because not all songs are written in a 4/4 key, we can easily have a different number of beats within the rhythm pattern. E.g, a rhythm pattern with a length of 2 seconds, in a 4/4 key will have 4 beats, hence a tempo of , which is a tempo of 120 BPM. On the other hand, if the rhythm pattern is written in a 3/4 key, these 2 seconds will only have 3 beats, which leads to a tempo of 90 BPM.
The second reason why we cannot assume that every rhythm pattern will always contain 4 beats is that our algorithm might sometimes find rhythm patterns that have a period that is factor different from the actual pattern. This happens mostly when the rhythm pattern itself is monotone and the song shows little rhythmic variation. (As we have explained for the song ``Tainted Love'')
As observed from our results, the Fourier analysis has little problems with harmonics, however it is less accurate than our technique. Therefore, a combination of both techniques might yield a high accuracy without too much problems of harmonics. Specifically, we could easily modify the algorithm such that it would in its first iteration fill the array with the spectrum of the envelope. Formally, line 4 of our algorithm becomes .
In this paper we have introduced our visualization technique, called beat graphs. A beat graph shows the structure of the music under a certain tempo. It shows rhythmic information, covering where breaks and beats are positioned and tempo information. Beat graphs can be quickly drawn and are a valuable tool for the digital DJ, because they can also be used as a fingerprint of songs.
Based on these beat graphs, we have developed an offline algorithm to determine the tempo of a song fully automatically. The algorithm works by shooting rays through the digital audio and checking the similarities between consecutive slices within the audio. To speed up the process of finding the best matching ray, we presented an optimized search algorithm that must only search 0.2% of the entire search space.
The BPM counter works fully correct in 82% of the cases. The other 17% are correctly measured but report a tempo that is an harmonic of the actual tempo. The remaining one percent is measured incorrectly . The accuracy of the measurement is 0.0340 BPM, which is enough to keep the drift of two songs below beat after 30'' (or to keep the drift below beat after 60''). Aside from being very accurate, our algorithm is also insensitive to breaks and gaps in the audio stream. The algorithm is 8.33 faster than real time on a 600 MHz Dell Optiplex, without making use of processor specific features.
The table below contains 150 songs, all which have been measured a) manually using beat-graphs, b) autmatically using our rayshooting technique, c) automatically using autocorrelation and d) automatically using a fourier analysis of the audio enveloppe. For every song we have compared the measured tempo against the actual tempo. In a number of cases this tempo is a multiple of the actual tempo beacuse the algorithm measures a period which contains a wrong number of actual beats. E.g, 5 beats, 7 beats, 3 beats and so on. Based on these harmonics we have rescaled the measurement and compared the reported tempo with the measured tempo. This denotes the measurement error. Only for the fourier analysis of the enveloppe we have avoided in doing so (this is reported in the colum: 'Before'). We did this because the fourier analysis measure the most prominent frequency, not the best matchin period. As such are the harmonics of this technique often much more wrong than the harmonics of the two other techniques. As such, fixing the measurement of the fourier technique might give a wrong impression. Therefore the before colum only takes into account the ones that were acutally measured correctly.
|Measurement Error (BPM)
|1.||BpmDj: Free DJ Tools for Linux Werner Van Belle 1999-2010 http://bpmdj.yellowcouch.org/|
|2.||Beatforce Computer DJ-ing System John Beuving 25 September 2001 http://beatforce.berlios.de/|
|3.||Hang the DJ: Automatic sequencing and seamless mixing of dance-music tracks Dave Cliff Technical report, Digital Media Systyems Departement, Hewlett-Pacakrd Laboratories, Bristol BS34 8QZ England, June 2000|
|4.||Alien Pump Tandu Distance To Goa 6, Label: Distance (Substance) Records, 1997|
|5.||LSD SImon Posford (Hallucinogen) Dragonfly Records, 1995|
|6.||X-Files Chakra & Edimis Retro 10 Years of Israeli Trance, Label: Phonokol, 2001|
|7.||Anniversary Walz Status Quo Label: Castle Music, 1990|
|8.||Certain Topics in Telegraph Transmission Theory Harry Nyquist AIEE Trans., 47:617-644, 1928|
|9.||Rolling On Chrome Aphrodelics remicex by Kruder & Dorfmeister Studio K7, 1990|
|10.||Tainted Love Soft Cell Warner, May 1996|
|11.||Music understanding at the beat level: Real-time beat tracking for audio signals M. Goto, Y. Muraoka Readings in Computational Auditory Scene Analysis, 1997|
|12.||Apparatus for detecting the number of beats Yamada, Kimura, Tomohiko, Funada, Takeaki, Inoshita, and Gen US Patent Nr 5,614,687, December 1995|
|13.||Estimation of tempo, micro time and time signature from percussive music Christian Uhle, Jürgen Herre Proceedings of the 6th International Conference on Digital Audio Effects (DAFX-03), London, UK, September 2003|
|14.||Tempo and beat analysis of acoustic musical signals Scheirer, Eric D Journal of the Acoustical Society of America, 103-1:588, January 1998|
|15.||Discrete-Time Signal Processing Alan V. Oppenheim, Ronald W. Schafer, John R. Buck Signal Processing Series. Prentice Hall, 1989|