Some MP3 files stuck at 99%

[joeyave]

I have some MP3 files that stuck at 99% for some reason. I've tried changing engines (r2, r3), changing clipping option etc.

Using latest version 3.1.2.

Is it a known issue? I can upload those files somewhere if needed.

Issue happens on MacOS and Ubuntu.

[cannam]

Not a known issue, to me at least - so thanks for reporting! If you can email me a link to an example file (at cannam@all-day-breakfast.com - or post it here if no copyright concerns) that would be great.

[joeyave]

https://drive.google.com/file/d/1yVCI4zFoHThCFluNP0fWMkfwCcsrOxNZ/view?usp=share_link

[joeyave]

Using --debug 3 shows that there is some kind of infinite loop:

available = 1140
retrieving block of 1024
available = 116
retrieving block of 116
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0
count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0

This line is repeated forever: count = 0, bs = 1024, frame = 11363328, frames = 11611802, final = 0

[cannam]

This is fixed in the repo now - would appreciate feedback if you are able to test. I'm intending to tag another minor release soon as well, so the fix will be in there.

To my relief this turned out not to be a bug in the stretcher itself, only in the command-line utility code - so it won't affect any other uses of the stretcher.

The problem was with the way it handled audio files that decoded to fewer sample frames than reported in the header information from libsndfile. Because they never reach the nominal end frame, the processing loop never completes, but keeps calling process with no frames repeatedly, as you saw. The fix is of course to terminate when the file stops decoding, regardless of how many frames it claims to have.

This isn't such an issue with most audio file formats, although the logic was most unsound even when it didn't cause problems in practice. For mp3s it seems more likely, presumably because the reported frame count is only approximate.

[joeyave]

Great! Thank you very much for such quick fix. Will try asap.

[joeyave]

Working good. Haven't encounter any errors so far.

[cannam]

Fixed in 3.1.3 and 3.2.0.