View Issue Details

IDProjectCategoryView StatusLast Update
0008863ardourbugspublic2022-01-21 22:43
Reporterkiilerix Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
PlatformRedhatOSLinuxOS Version(any)
Product Version6.9 
Summary0008863: flac file works until it inevitably triggers seek eror and gets quiet
DescriptionI 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 ReproduceThe 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 InformationI 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

TagsNo tags attached.

Activities

kiilerix

2022-01-21 00:37

reporter   ~0026306

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 )

x42

2022-01-21 04:08

administrator   ~0026307

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?

kiilerix

2022-01-21 22:42

reporter   ~0026308

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.

kiilerix

2022-01-21 22:43

reporter   ~0026309

The problem is in flac libs - not in Ardour.

Issue History

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