View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008863 | ardour | bugs | public | 2022-01-20 20:33 | 2022-01-21 22:43 |
Reporter | kiilerix | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | Redhat | OS | Linux | OS Version | (any) |
Product Version | 6.9 | ||||
Summary | 0008863: flac file works until it inevitably triggers seek eror and gets quiet | ||||
Description | I have one of hundred similar tracks that shows this problem in ardour: after a while, navigating many similar tracks, listening and doing stuff, this track becomes quiet. | ||||
Steps To Reproduce | The problem is "quite" reproducible for me, both in 6.9 and "7": Import "12 ORGAN R.flac" on a new track, and use some combination of space and left and right arrow to start and stop playing in different places. Sometimes the problem appears already before starting playback - I have seen the peak building fail and showing a truncated graph. Usually, the track starts out working correctly, with audio playing and signal shown in the track VU meter. At some point, usually after less than something like 50 key presses, the channel becomes quiet - no signal on the VU meter. The log seems to consistently show a seek error when things go wrong. With a bit of extra debug logging it shows up like: ... 2022-01-20T20:43:53 [ERROR]: SndFileSource: seek to sample 90058240 within 12 ORGAN R.flac 2022-01-20T20:43:53 [ERROR]: SndFileSource: seek to sample 90058752 within 12 ORGAN R.flac 2022-01-20T20:43:53 [ERROR]: SndFileSource: seek to sample 90059264 within 12 ORGAN R.flac 2022-01-20T20:43:53 [ERROR]: SndFileSource: seek to sample 90059776 within 12 ORGAN R.flac 2022-01-20T20:43:53 [ERROR]: SndFileSource: could not seek to sample 90059776 within 12 ORGAN R.flac (No Error.) - and from then on nothing works. The only way to get signal back is to restart the session. I have tried to reproduce the problem in a standalone C++ program that was seeking and reading from this flac file in a pattern that seemed similar, but haven't been able to reproduce it that way. I have not been able to reproduce with the corresponding "L" file - it works flawlessly. It also works after re-encoding the file with the "flac" command line tool gives a file with same content that also doesn't show the problem. That works as a temporary workaround. | ||||
Additional Information | I discussed this issue briefly with x42 on IRC 2021-12-18. The problematic flac file was created by Soundcraft Ui24R writing flac directly to USB. I have (temporarily) made the problem-triggering 160 MB file available on https://wetransfer.com/downloads/1eadb1aa46ba40b0e301f745ee4b782120220120202728/5db0efc9546315e640f764b310cca39c20220120202728/dea7f9 I'm running on Fedora, reproduced both with Fedora ardour 6.9 and with custom "7" build on the master branch. libsndfile-1.0.31-6.fc35.x86_64 flac-libs-1.3.3-9.fc35.x86_64 | ||||
Tags | No tags attached. | ||||
|
It seems like the problem can be reproduced with xiph flac directly: https://github.com/xiph/flac/issues/276 (Before getting this far, I also reproduced with libsndfile directly: https://github.com/libsndfile/libsndfile/issues/806 ) |
|
Thanks for tracking this down. So it seems we have to wait until xiph/flac (and libsndfile) address this. Does this happen with any file? In all your bug reports you mentioned `12 ORGAN R.flac` -- can you rule out that the file is corrupt? |
|
We analyzed the problem in flac and I'm testing a fix/workaround. When seeking in a file with variable length compression, it just has to seek to a "random" location, and read until it looks like a new frame is starting. The data in the frame will help to bisect for the right location. Flac doesn't use any kind of escaping of the data, so data *can* look like a new frame is starting ... but with "wrong" data that will mislead the bisection. That's what happened in this case. The problem can thus happen in well-formed - but unfortunate files. There is no corruption involved. Flac could however do much more to see if it actually is a valid frame start - such as checking the crc. Doing that will mitigate the problem even more. Seeking is thus expensive and risky. It might thus be a bit unfortunate that Ardour tend to do a lot of seeks in small chunks of 8k - for example when building peak files. A chunk size of something like 1 MB will have much less overhead and shouldn't be a problem. Ardour could perhaps also handle this failure mode better, but that should mainly be fixed in libsndfile. Anyway, this bug report can be closed. |
|
The problem is in flac libs - not in Ardour. |
Date Modified | Username | Field | Change |
---|---|---|---|
2022-01-20 20:33 | kiilerix | New Issue | |
2022-01-21 00:37 | kiilerix | Note Added: 0026306 | |
2022-01-21 04:08 | x42 | Note Added: 0026307 | |
2022-01-21 22:42 | kiilerix | Note Added: 0026308 | |
2022-01-21 22:43 | kiilerix | Status | new => closed |
2022-01-21 22:43 | kiilerix | Resolution | open => no change required |
2022-01-21 22:43 | kiilerix | Note Added: 0026309 |