aubio / aubio

a library for audio and music analysis
https://aubio.org
GNU General Public License v3.0
3.29k stars 376 forks source link

aubioonset returns sample values greater than the length of the file #155

Open woolgathering opened 6 years ago

woolgathering commented 6 years ago

When running aubioonset with the -T samples flag, a number larger than the size of the file is returned as the final "onset". This number is often 256 samples more than the length of the file but appears to sometimes be less, depending on the file.

roger@RAM: $ soxi -V5 test.wav
soxi INFO formats: detected file format type `wav'
soxi DBUG wav: WAV Chunk fmt
soxi WARN wav: wave header missing extended part of fmt chunk
soxi DBUG wav: WAV Chunk bext
soxi DBUG wav: WAV Chunk junk
soxi DBUG wav: WAV Chunk data
soxi DBUG wav: Reading Wave file: IEEE Float format, 1 channel, 44100 samp/sec
soxi DBUG wav:         176400 byte/sec, 4 block align, 32 bits/samp, 391168 data bytes
soxi DBUG wav:         97792 Samps/chans

Input File     : 'test.wav'
Channels       : 1
Sample Rate    : 44100
Precision      : 24-bit
Duration       : 00:00:02.22 = 97792 samples = 166.313 CDDA sectors
File Size      : 392k
Bit Rate       : 1.41M
Sample Encoding: 32-bit Floating Point PCM

roger@RAM: $ aubioonset -i test.wav -T samples
0
2065
5003
19092
60913
98048

Here we have the last onset at 98048 and the length of the file at 97792. The difference is 256. I'm thinking that this maybe has something to do with the soxi warning regarding the WAV header?

piem commented 6 years ago

hi @woolgathering and thank you for the report. This doesn't look related to the file or its headers. The problem is that the onset detection algorithm is not aware of the end-of-file being reached. As it processes the last block of samples (typically 256 samples), an onset is detected and its timestamp is set passed the actual end-of-file.

I'm not sure what is the best way to address this, apart from post-processing the output to ignore onsets detected too late, or clamp them back to the end-of-file timestamp.

woolgathering commented 6 years ago

Yes, I just did post-processing on the output but I wasn't sure if this was a known issue or not, hence my posting. Thanks for the response!