I have audio files and timestamped fragment transcriptions that I have force-aligned with third party software.

Unfortunately the software places the end of each fragment right before the start of the next fragment, so if you try to play just one fragment from the audio file it will bleed over to the next fragment.

Here's a visualization of the waveform: WaveForm 1

The red line is the automatically produced timestamp for the end of one fragment, and the start of another. The left and right sides are 2 seconds of audio on either end of that timestamp. As you can see it's placed right up against the next time audio starts to output.

The blue and purple lines are two different algorithms I've used to try to identify the middle of the trough. In this case, the blue one worked, but in others it doesn't:

WaveForm 2 WaveForm 3 WaveForm 4

The data is a list of floating point numbers ranging from 0 to 1. They represent a normalized and bucketed version of decoded 48Hz mp3 audio. As you can see, in some cases there's a range of near zero values. In others there's varying degrees of "low volume", but always a visually-identifiable trough.

Can anyone recommend a method or algorithm for working backwards from the red line and finding the middle of the first trough? TIA!

  • $\begingroup$ It seems like taking the middle point between the purple and the red line would work well in these instances. Have you tried this on others? $\endgroup$ Oct 25, 2023 at 21:30
  • $\begingroup$ @StephanKolassa I had not, yet. It works on some but not this one for instance: imgur.com/a/82E4JFA I'm having better luck (but not 100%) using a method that looks for a grouping of 5 values where the median value is > 7x the minimum of the preceding set of values. It worked on a bunch then failed on this: imgur.com/a/ubsWcC0 (the purple line is the updated alg in each) $\endgroup$
    – c0bra
    Oct 25, 2023 at 21:52
  • 5
    $\begingroup$ This is a no-free-lunch problem. The only reliable answer is hand inputting the value. But if I were approaching it as a stat problem, I would define "silence" based on some bimodal modeling of the collapsed audio file. Then, having defined duration of tracks that are "silent", define long periods of silence as a track break, and take the midpoint as the time break. $\endgroup$
    – AdamO
    Oct 26, 2023 at 4:56

1 Answer 1


Trough finding can be seen "peak finding" just with the feature being inverted. Peak finding is a common problem in digital signal processing, including in audio. I would try computing the soundlevel (RMS or in dB), and try to use librosa.util.peak_pick. You can then try to snap to the closest peak forward in time (below a reasonable amount of time).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.