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

[Paul Brossier]

Hi Peter, hi all,

On 12/07/2016 12:32 PM, Peter P. wrote:
> Hi list, hi Paul,
> 
> I already sent this to contact at aubio.org last week. I am
> including it below (with one of the questions slightly modified to
> reflect my current state of knowledge). Thank you for any ideas and
> please excuse a possible cross-posting.

I have received your mail, sorry for the delay in processing it. Posting
such questions to the list is appreciated, so it will be available for
everyone to read.

> 
> --------------------------->
> 
> Hi,
> 
> I found out that aubiocut will write its output file as 16bit Signed
> Integer PCM regardless of the encoding of the input file (24bit
> signed-integer, 8bit unsigned-integer). Am I correct?

Yes, the output is limited to 16 bit for now, due to limitations of the
sink modules (src/io/sink*.c). The python module manipulate the samples
are numpy.float32 though.

> I was surprised that aubiocut takes wav files with more than 2 channels
> and writes wav files with the correct number of
>  channels to disk again. Are all these channels considered in the
> analysis?

Yes, currently aubiocut first extracts a list of timestamps from a mixed
down version of the audio, then uses these stamps to slice the
multi-channel original.

> 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)

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

> 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.

> 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.

> 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?

Best, Paul

> Thank you for all answers and these great tools!
> best, Peter
> 
> _______________________________________________
> aubio-user mailing list
> aubio-user at aubio.org
> https://lists.aubio.org/listinfo/aubio-user
>