[aubio-user] [peterparker at fastmail.com: some questions]

[Paul Brossier]

Hi Peter and all,

On 12/11/2016 02:42 PM, Peter P. wrote:
> Would I have to specify the input sampling rate manually when piping
> audio via stdin to aubiocut/onset?

This will depend on a number of parameters:

 - which external libraries were used to compile aubio with
(ffmpeg/libav, libsndfile, CoreAudio)

 - which file format are you sending through the pipe: uncompressed
(aiff, wav, ...) or compressed (ogg, flac, mp3, mov, ...).

Some formats include sampling rate in the header of the file, so that it
can be obtained after reading only a few bytes in the file. Others
include it at the end of the file, or not at all, in which case you
would have to specify it manually.

To find out a combination that works, the best way is to try out.

>> aubiocut should set the input filename to '/dev/stdin' if none is given.

> In my case it doesn't ("no file name given") but if I specify - as input
> file it works.

libsndfile will try to open '-' as /dev/stdin on linux, but libav/ffmpeg
or CoreAudio will not. So depending on the external libraries linked in
aubio, and depending on the host platform, '-' might or might not work.

>> You could ask aubioonset to emit timestamps in samples, with '-T
>> samples'. The option '-T/--time-format <samples|ms|seconds>' is
>> available since 0.4.3, but is not in aubiocut yet.

> Thank you! I am trying to change my script to use aubioonset rather than
> aubiocut now. Am I right that aubiocut's -M parameter is not (yet)
> implemented in aubioonset though?

It is now, in the latest git revision.

> Interestingly I am getting one more onset at end of the list posted to the
> console with aubioonset than with aubiocut.

This was a bug, which should be fixed now, also in the latest git.

> For a file that has 874292 samples (as reported by soxi -s), aubioonset
> -T samples reports its last onset at 874496 samples. Could that be the
> end of an analysis window that lasts longer than the actual audio data
> inside the window? 874496 / 512 gives the integer value 1708.

Correct, this is the same bug as above, that added a trailing onset at
the end of the file, and should also be fixed in git now.

>>> The Debian manpage is possibly ambigous about the default threshold
>>> value. Both 0.1 and 0.3 are given.

>> Good catch, thanks! This will be fixed in the next version.

> Just saw that it is present in aubiocut and aubioonset's manpages. Also
> aubioonset's manpage explains the -s paramter as "Set  the  silence
> threshold, in dB, under which the pitch will not be detected." where
> pitch should be onset possibly.

The descriptions of options `-s` and `-t` in git have been somewhat
improved now, check the manpages in current git.

>> Aside from the limited sink output format, what other reasons make you
>> prefer using sox for slicing?

> I am storing the onset times in a bash array and am thus able to
> randomize the onset times to create a garbled-up remix of my input file.
> I could iterate in stepsizes larger than 1 over this very array
> (effectively mimicking the --cut-every-nslices option).

It seems to me it could be easier to do that in custom python script,
which would first create a list of shuffled and spread out slices, then
use aubio's `slice_source_at_stamps` to splice the file as wanted.

Best wishes,
Paul