Last ~0.5s always truncated when resampling audio #162
Comments
|
Could you check if any of the flush calls are returning errors? |
|
Just changed it to unwrap the one unchecked flush call as so: audio_decoder.flush();
while let Some(_) = resampler.flush(&mut resampled_audio).unwrap() {
println!("Getting some bytes");
data.append(&mut get_samples(&resampled_audio));
}No error, also I put in a print in that loop and it returns |
|
Oh if the resampler returns the last of the audio in that flush call the first time would it then return EDIT: Nope didn't change anything, so now the changed code for the resampler is: println!("Flush decoder and read last bits");
audio_decoder.flush();
while resampler.delay().is_some() {
println!("Flushing");
resampler.flush(&mut resampled_audio).unwrap();
data.append(&mut get_samples(&resampled_audio));
}And flushing is never printed. |
|
Another observation, this time I went for an 8KHz wav and 8KHz mp3 as the source audios so the resampler shouldn't change the audio in the slightest. This is the input wav file and output wav file. They match exactly
This is the input mp3 file and output wav file, we can see again ~0.5s is removed from the end (11.23s vs 10.52s).
Not sure if this suggests misuse of the audio decoder as mp3 decoding is more involved than wav... I believe mp3 is planar data not packed so the resampler may be doing the work to convert between the two layouts but nothing else? |
|
Yeah I feel like something is not being fully flushed somewhere. I will try to dig in as soon as I have time, but do keep digging, it might be inside the library itself, too. |
|
Yeah I've started going over the library code this afternoon and ffmpeg C examples to see if I can find anything that stands out to me. I'll also enable the trace logging but I tried that before I had the minimal example and nothing stood out |
|
Output for the 44100Hz wav with the ffmpeg trace logging enabled, most of it's the probe stuff no real logging from resampler 😞 Also, edited first post to add version info for ffmpeg into the issue. |
|
I think I figured out the issue. I tried forking rust-ffmpeg to prevent rounding down, but this didn't completely fix the problem because I found 2 workarounds
Tangentially, it might make sense to fix |
|
I like workaround number 2, and I think I like delay returning a more meaningful value. |
So there's no chance of the resampler requiring >1 flush call and two adjacent ones returning the same number of samples? |
|
By 'data' I'm referring to the final vec of samples. If flush returns no samples, it's length wont change. As long as the audio frame being passed to flush is non-empty, flush returning no samples should indicate there is no more buffered output. |
So this may well be a user error so I've extracted out the relevant code to create a minimal example and pushed it to here: https://github.com/xd009642/resampling_example the behaviour is very consistent though and seems to be about the same amount of data missing from the end regardless of file length (I've tried this with 3 wave files going from 44100Hz->8000Hz some stereo some mono).
This example will load the audio file at 44100Hz and resample it to 8000Hz. Whenever I do this I find that the end of the audio file gets chopped off. Below is a screenshot of audacity showing the source file as the first track and the output as the second track.
I wonder if this could be related to how I'm flushing the resampler at the end?
EDIT ffmpeg version info, but I've also observed this behaviour on ffmpeg 4.3.2 as well:
The text was updated successfully, but these errors were encountered: