local variable 'start_ii' referenced before assignment

[dumbcoder2399]

Steps to reproduce

Expected behavior

I am running the code given in https://www.geeksforgeeks.org/python-speech-recognition-on-large-audio-files/ to transcribe large wav files

Actual behavior

But i am getting this error

UnboundLocalError Traceback (most recent call last)
in
100
101
--> 102 silence_based_conversion("creedoscar.wav")
103

in silence_based_conversion(path)
29 # consider it silent if quieter than -16 dBFS
30 # adjust this per requirement
---> 31 silence_thresh = -16
32 )
33

~/.local/lib/python3.6/site-packages/pydub/silence.py in split_on_silence(audio_segment, min_silence_len, silence_thresh, keep_silence, seek_step)
132 start_min = end_max
133
--> 134 chunks.append(audio_segment[max(start_min, start_ii - keep_silence):
135 min(len(audio_segment), end_ii + keep_silence)])
136

UnboundLocalError: local variable 'start_ii' referenced before assignment

Your System configuration

• Python version: Python 3.6.9
• Pydub version: 0.24.0
• ffmpeg or avlib?: ffmpeg
• ffmpeg/avlib version: ffmpeg version 3.4.6-0ubuntu0.18.04.1

Is there an audio file you can include to help us reproduce?

You can include the audio file in this issue - just put it in a zip file and drag/drop the zip file into the github issue.

[rodolfosaraiva]

same error here

[mxliao]

same error here

[GreyAlien502]

Thanks for reporting.
This bug was introduced in pull request #360.
I am working on a fix.

[ghost]

Thanks @GreyAlien502 I am also in the same situation...

[florian-sattler]

I observed this issue too. It occurs under two distinct circumstances:

1. The whole audio is considered silent.
2. No silence was found in the sample.

One might need to handle those events separately as both result in an empty chunks list, however in the first case, audio might be dropped completely (according to keep_silence ) while the audio should be kept in the second case.

In the first case not_silence_ranges is empty ([]), in the second case not_silence_ranges has one element ([ [0, XXX] ])

[GreyAlien502]

@florian-sattler, thanks for pointing out that fault in my fix.

The problem with request #483 is that the existence of one sole non-silent segment does not mean that there is no silence before or after that segment;
we still need to handle keep_silence the same way we would if there were more than one segment.

[florian-sattler]

I really like your approach using output_ranges and your test cases!

I wonder if it would be better to add the clipping with explicit variables such as min_index and max_index before the creation of output_ranges 🤔 This would allow to use them in the list comprehension.

This way the clipping would be a bit clearer to maintain. Also consecutive negative values would be clipped as well. However I'm not sure they can even be generated by detect_silence.

Also: Should the 135 ms fix really be a part of this? 😁

[ghost]

Hello,
Was there a fix to this issue ? or a workaround or not yet ?
Thank you!

[GreyAlien502]

@florian-sattler,
I've made a change based on your suggestion, and i think it clears things up considerably.

consecutive negative values

The negative values don't come from detect_silence, they come from subtracting keep_silence from the range's start index.
So, they can come in later ranges, but if they do it would mean that those ranges overlap with the previous, so they'd need to be handled like any other chunk that wants to keep more silence than there is.

Should the 135 ms fix really be a part of this?

It really shouldn't, but i was hoping it would fix the failed test, since we can't release till those are running, and i'd like to get a working version out as soon as possible.
Since it didn't fix the issue, i guess i'll remove it for now.
Unfortunately, it seems to be an unrelated error and it only comes up on the Windows tests, so i can't reproduce it.

[GreyAlien502]

@bacloud14, there is no official fix released.
If you need the functionality to work for your personal installation right now, you can always install from a pull request that fixes that feature like so:

pip install --upgrade git+https://github.com/jiaaro/pydub.git@refs/pull/482/merge

If you decide to do this, there are a few caveats:

1. You should always look over the code changes to make sure you trust them.
2. The pull request might introduce more bugs. You will need to use your judgement here as well.
3. Be sure to reinstall from the official source once the feature you need has been merged. (e.g. pip --upgrade pydub should do it)

[florian-sattler]

@GreyAlien502 Thank you for your changes.

I checked out your code on windows too and am able to reproduce a failing test, however the error is different.

As this error is clearly unrelated to this issue, is it possible to merge this fix?

[GreyAlien502]

@florian-sattler, to merge despite failing tests, @jiaaro would have to take care of it & idk what exactly it would involve or when he'll have time.

[jiaaro]

@GreyAlien502 @florian-sattler seems there is a bug in the development build (aka "latest") of ffmpeg. in #487 I switched the appveyor config to be pinned to ffmpeg 4.2.3, and added a single configuration that uses ffmpeg latest but allows failures

[jiaaro]

@GreyAlien502 feel free to review and approve/merge if you think it's solid

[GreyAlien502]

@jiaaro, thanks for the fix, i was getting really confounded by those failures.

I'm working on a request for the change log and version bump so we can get this fix released.

[GreyAlien502]

Version 0.24.1 has been published, so this should no longer be a problem for anyone running the latest version.