-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
This avoids returning non-sensical results, or in case of history-based loudness range calculations a panic. All filter processing already handles NaN gracefully. Fixes #43
🥳 |
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.The text was updated successfully, but these errors were encountered: