Panic when calling loudness_range #43
Comments
|
Thanks for reporting this. The problem is in combined.sort_unstable_by(|a, b| a.partial_cmp(b).unwrap());Apparently the history contains NaNs sometimes? Can you provide a testcase for this, even if it only triggers rarely? |
|
@overdrivenpotato Any updates here? |
|
I've shifted off that particular project but for some added context: This was triggered by feeding a simple non-NaN 96kHz FLAC input into FFMPEG, which was then decoded, resampled to 96kHz (same rate, no-op?), and then fed into ebur128. I would imagine the data coming out of the FFMPEG FLAC decoder/resampler is constant as the FLAC input was always identical, and the sample rate was always the same between I/O. The spurious nature of the panic is puzzling. |
|
Indeed. If you can somehow produce a testcase for this, even if it only triggers the problem sometimes, that would be really great. I don't see how any of these values can end up as NaN so without a testcase there's not much I can do. Would that be possible for you? Otherwise I guess we can close this issue until someone can reproduce it :) |
|
Hello, think i've run into same or a simliar problem and can reproduce it with: #[test]
fn loudness_range_panic() {
// at least this many samples are needed to trigger panic
let mut data = vec![0.0f32; 44_100*80];
for out in data.chunks_exact_mut(2) {
out[0] = f32::INFINITY;
out[1] = f32::NEG_INFINITY;
}
let mut ebu = EbuR128::new(2, 44_100, Mode::I | Mode::TRUE_PEAK | Mode::LRA,).unwrap();
ebu.add_frames_f32(&data).unwrap();
assert_float_eq!(
ebu.loudness_range().unwrap(),
0.0,
abs <= 0.000001
);
}Panic: The file that triggers this for me is a wav file with fmt audio format 3 (32 bit little endian float PCM) filled with only left / right samples that are the bytes |
|
Thanks for the testcase, I'll look into this :) |
If the calculation ends up with NaN we reset the filter state and skip this sample, which hopefully leads to better results in the future. Fixes #43
|
This is fixed in #55 |
If the calculation ends up with NaN we reset the filter state and skip this sample, which hopefully leads to better results in the future. Fixes #43
If the calculation ends up with NaN we reset the filter state and skip this sample, which hopefully leads to better results in the future. Fixes #43
If the calculation ends up with NaN we reset the filter state and skip this sample, which hopefully leads to better results in the future. Fixes #43
Hello, thanks for making this library :-)
There seems to be a bug when calling
loudness_rangethat occasionally triggers a panic. I've attached a stack trace with the relevant calls below. I've tried unsuccessfully to build a repro case but in my application the error is somewhat rare. Even with the same input data every time, it will fail spuriously about 1% of the time. For some context, I'm testing with a ~40 second 96kHz stereo clip buffered in asf32samples.The text was updated successfully, but these errors were encountered: