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

[Peter P.]

Hi Paul,

and thanks for your response! Please find my answers below.

* Paul Brossier <piem at aubio.org> [2016-12-08 15:11]:
[...] 
> > Could aubiocut receive its input audio data from stdin instead from a
> > file? This would make pre-processing/integration with SoX super easy
> > without having to write temporary files (see sox manpage for examples).
> 
> You should be able to use '/dev/stdin' to read from standard input:
> 
> $ aubiocut drum.wav > /tmp/1
> found 18 timestamps in drum.wav (total 2.95s at 44100Hz)
> 
> $ cat drum.wav | aubiocut /dev/stdin > /tmp/1
> found 18 timestamps in /dev/stdin (total 2.95s at 44100Hz)
This is great, thak you!
Would I have to specify the input sampling rate manually when piping
audio via stdin to aubiocut/onset?
 
> 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.

> > I am trying to use aubiocut to give me timestamps of onsets, but would
> > prefer to do the cutting/splicing in SoX. For this I am using the onset
> > times in samples rather than in seconds. If I multiply an onset time
> > from aubiocut by the sampling rate of the file I am getting non-integer
> > values. For example: 0.1866 * 44100 = 8229.1
> > All seems to be fine just truncating the .1 sample, but I am curious
> > about the origins of that .1 fraction.
> 
> 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?

Interestingly I am getting one more onset at end of the list posted to the
console with aubioonset than with aubiocut.
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.
 
> > 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.
 
> > What would a use-case be for the --cut-until-nslices option? I would
> > like to use it to get larger and less slices of audio. In order for this
> > to work would it be possible to have aubiocut --cut-until-nslices post
> > the values for that to the console (instead of every slice)?
> 
> This option was used mainly to test that the slicer would work
> correctly, even on overlapping regions. Clearly aubiocut could do with
> an additional `--cut-every-nslices` option, for instance to slice every
> 4 beats.
> 
> I guess I could create another script just for slicing at a given list
> of timestamps. The function aubio.slice_source_at_stamps in
> aubio/slicing.py does that.
> 
> 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).

Thank you again for your kind support!
Peter