Hi! We are using libFLAC++ in our project for both encoding and decoding. I've found an issue where ::FLAC::Decoder::Stream::seek_absolute() fails with very short files (less than 2500 frames or so.) I've attached an example of such a file. The failure case is in stream_decoder.c, line 3071. The comment above this case reads "check if the bounds are still ok." The sample we're seeking to is in range and its particular value doesn't seem to matter (we see this commonly when seeking to sample 0.) I haven't been able to figure out what this failure case means - could someone explain the comment and whether it's expected that this should fail under normal circumstances? I am not set up to easily put together a minimal repro, but I can work on that if this is difficult for others to reproduce. Thanks for your help! -- Luke Bradford Senior Software Engineer luke at izotope.com iZotope, Inc. www.izotope.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20161115/5cd00229/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 5b946fcf608deced9a84609d51517a419e5f4f99.flac Type: audio/flac Size: 4126 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20161115/5cd00229/attachment.flac>
Luke Bradford wrote:> I am not set up to easily put together a minimal repro, but I can work on > that if this is difficult for others to reproduce.I was hoping to tackle this last weekend but I didn't manage to find time. A small test case would be very useful indeed. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
I was wondering when it would be useful to compress very short audio files. The answer may be when there are lots of files, for instance in the case of sound fonts, or a large collection of transients. Probably it would be better to compress the whole collection as a single large file obtained by juxtaposing the short clips, with cues or marks to separate the original files. May be this allows a more efficient way to deal with headers. Federico On 21/11/2016 16:28, Erik de Castro Lopo wrote:> Luke Bradford wrote: > >> I am not set up to easily put together a minimal repro, but I can work on >> that if this is difficult for others to reproduce. > I was hoping to tackle this last weekend but I didn't manage to find > time. A small test case would be very useful indeed. > > Erik-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20161121/e2843263/attachment.html>