Closed overdrivenpotato closed 5 months ago
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:
---- ebur128::tests::loudness_range_panic stdout ----
thread 'ebur128::tests::loudness_range_panic' panicked at src/history.rs:413:67:
called `Option::unwrap()` on a `None` value
stack backtrace:
0: rust_begin_unwind
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
2: core::panicking::panic
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:144:5
3: core::slice::sort::recurse
4: core::slice::sort::quicksort
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/slice/sort.rs:904:5
5: core::slice::<impl [T]>::sort_unstable_by
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/slice/mod.rs:3008:9
6: ebur128::history::History::loudness_range_multiple
at ./src/history.rs:413:17
7: ebur128::history::History::loudness_range
at ./src/history.rs:357:9
8: ebur128::ebur128::EbuR128::loudness_range
at ./src/ebur128.rs:864:12
9: ebur128::ebur128::tests::loudness_range_panic
at ./src/ebur128.rs:1517:13
10: ebur128::ebur128::tests::loudness_range_panic::{{closure}}
at ./src/ebur128.rs:1506:30
11: core::ops::function::FnOnce::call_once
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
12: core::ops::function::FnOnce::call_once
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
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 00 00 80 7f
/ 00 00 80 ff
which seems to be Inf / -Inf.
Thanks for the testcase, I'll look into this :)
This is fixed in https://github.com/sdroege/ebur128/pull/55
🥳
This is fixed in 0.1.9. Sorry for the delay!
No worries at all and btw thanks for a creating and maintaining this create!
Hello, thanks for making this library :-)
There seems to be a bug when calling
loudness_range
that 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 asf32
samples.