Recording truncated

[Mte90]

Describe the bug Since 2 weeks unsilence is not working anymore to me.

To Reproduce

unsilence $1 pulito-$1 -stt 0.4 -ao -sl '-18' -t 4

I always used in this way to clean my weekly podcast. As example if I run this on the mp3 of this episode https://funkwhale.it/library/tracks/2065/ (that I cleaned manually after the issue to publish it) Unsilence detect the silence, and generate a cleaned file. With the original before the manual clean it was truncating the audio.

So if you download https://funkwhale.it/library/tracks/2057/ the previous episode that wasn't cleaned manually the problem is happening

It is again everything working but the audio file generated: Instead is just 2~ minutes

Desktop (please complete the following information):

• OS + version: Debian sid
• Python version 3.9.7
• FFMPEG version 4.4-6

[Mte90]

It is happened also with this recording https://www.spreaker.com/user/mte90/50special

At the end there are just 8 minutes but the recording so more long

[Mte90]

So another info I had issue with the podcast recorded today. The recording was failing again on 31 minutes there were just the first 13 minutes. So I started editing the original audio and removing some silences (just 6 seconds) and now unsilence detected everything and generated a right file.

[lagmoellertim]

There seems to be a bug in the Interval Combination Method, since the only parameter that fails is silence_level, which only influences the Interval Size and the FFMPEG Command directly. Currently, I am sadly a little short on time, but this is on my todo to check what is wrong.

[Mte90]

Any updates for this?

This tool worked very good as now and migrate to another one...

[Mte90]

@lagmoellertim just a ping

[Garbaz]

I have the same issue. If I try to unsilence a certain ~47min file, which according to the output of unsilence should result in a ~42min file, I instead just get the first ~6min as the result.

Observations:

• Adding drop-corrupted-intervals doesn't change anything.
• Changing the silence-level to -40, which should result in a file almost identical to the original, does give me a bigger file, but it still is missing a part at the end, being only ~40min long.
• Changing the silent-speed to 6 does result in a complete file.

Additional note: I tried a few different files, and the "Combining Intervals" progress bar always stays at 0%, and the tool pretty much instantly finishes the moment the "Rendering Intervals" progress bar is at 100%, irrespective of whether the tool works correctly or doesn't. So while this is curious, it doesn't appear to directly correlate with this bug.

[Mte90]

@lagmoellertim can you help us? If I get some hints I can try to do myself the patch to the project.

[Garbaz]

Further Observations:

Does work with MP3 in / WAV out

Running the tool on exactly the same input file, but giving the output file as a WAV instead of MP3 does result in a complete file. However, the "Combining Intervals" bar still doesn't move.

Doesn't work with WAV in / MP3 out

Results in a ~16min file.

Doesn't work with --threads 1

Still the same ~6min file.

[Garbaz]

Investigation

When I run the ffmpeg command generated in MediaRenderer.__concat_intervals manually:

ffmpeg -f concat -safe 0 -i conc.txt -c copy -y -loglevel verbose test.mp3

where the files listed in conc.txt are simply stolen from the .tmp/* folder generated by unsilence, I get an interesting output, that being that the ffmpeg runs fine until it hits out_155.mp3, where it complains:

And voila, the file I get out is the ~6min one I was getting earlier.

If I try to open out_155.mp3 with mpv, it just spits Failed to recognize file format. back at me. However, the same happens if I open some of the other files. If I just let mpv play through all out_*.mp3 files:

find . -name "out_*" | sort -V | xargs mpv

I get every few files a Failed to recognize file format. and that file is skipped in playback.

However, except for out_155.mp3, all these files that aren't recognized by mpv are 1140 bytes in size and only raise a warning from ffmpeg: "Format mp3 detected only with low score of 1, misdetection possible!". out_155.mp3 itself is 1976 bytes in size.

If I insert a print(console_output) in RenderInvervalThread.__render_interval and look at what the ffmpeg command there, which is generating the file, has to say about out_155.mp3, then it doesn't appear to be different to any other intervals, however what is noticeable is that the interval is, after speedup, incredibly short (time=00:00:00.07). Though the other intervals (the 1140 byte files) all are even shorter (time=00:00:00.02).

Conclusion

Given all the above, it appears to me that there just seems to be some error in ffmpeg which messes up these super short MP3 files. And I'm not gonna start digging around in the ffmpeg source to figure out why.

So the best I can come up with to resolve the problem, is to ensure that we don't include files that ffmpeg doesn't like in the final concatenation. Ideally we could just tell ffmpeg's concat script to skip any files it can't read, but as far as I can tell, there doesn't appear to be an option for that. However, we can manually check with ffprobe whether ffmpeg does like a certain file, and ignore files that it doesn't. That's not very pretty, but it works and is the only reasonable solution I can come up with.

I have implemented this and created a pull request (#140).

[lagmoellertim]

Hey, sorry for the late response, I was pretty short on time lately. I will look at this issue and your fix till the end of the week so you can finally use this tool again 👍

[lagmoellertim]

If this only happens if the resulting files are very short, couldn't a flag that specifies the minimum length of an interval after speedup be used? At least this would not increase the total rendering time like checking each interval with ffprobe would do.

[Mte90]

I have issues also with files of 40 minutes so and using it with the parameter in the first ticket comment (there are also some files that replicate the issue).

[Garbaz]

If this only happens if the resulting files are very short, couldn't a flag that specifies the minimum length of an interval after speedup be used? At least this would not increase the total rendering time like checking each interval with ffprobe would do.

That would be neater, I agree.

I have checked and all the intervals that are questionable (mpv doesn't like them, but ffmpeg's concat script accepts them) are 0.05s long. The one interval neither mpv nor the concat script likes is 0.07s long. And the shortest good intervals are 0.08s long.

So if we could ensure that all invervals are maybe at least 0.1s long, that should resolve the issue, assuming that the length of the intervals really is the problem (which all signs seem to be pointing towards, but I'm not comfortable enough with audio codecs to say whether this makes sense, or whether arbitrarily making them at lest 0.1s long solves the problem in all cases).

Just skipping all too short intervals won't do, since we don't know how many short intervals we get in a row, and so if they add up, we might skip noticeable lengths of audio. So instead, we should make sure the intervals just aren't sped up too much to get that short. I can look into implementing that maybe tomorrow. From what I have gleaned looking at the code, this shouldn't be too difficult.

For now, I will make the slow way default behavior as you suggested in the PR.

[Garbaz]

I have issues also with files of 40 minutes so and using it with the parameter in the first ticket comment (there are also some files that replicate the issue).

The length of the total file is not what they are referring to (my problematic file also is around 40mins long), but the length of the individual interval files the program generates as an intermediate step.

[lagmoellertim]

Since I merged PR #140, this problem should hopefully be fixed now.

[Mte90]

I am testing with https://funkwhale.it/library/tracks/2057/

Report this

But in reality the audio is 23:05 instead of 22:11 in the output file.