[flac-dev] Seek failure with very short files

[Robert Kausch]

Hi Luke,

You need to set *bytes to the number of bytes actually read in 
read_callback. After that, you can drop your special handling of 
uBytesRemaining == 0 in tell_callback. It's not necessary.

Also, on Windows at least, you need to pass O_BINARY when opening the 
file and open the FILE pointer in "rb" mode.

This should help.

BR, Robert

----
Robert Kausch
robert.kausch at freac.org

Am 07.12.2016 um 19:58 schrieb Luke Bradford:
> Hi all,
>
> Thanks in advance for your help, and sorry for the slow reply. I've 
> created a small OS X example project 
> <https://drive.google.com/file/d/0B8vFUUth7NpvRFI0MmI2bVJNNEU/view?usp=sharing> 
> that reproduces the issue. (I've run into the size limit for emails on 
> this list so I've put it on Google Drive.) The program just 
> initializes a libFLAC++ stream decoder for a given file and attempts 
> to seek to frame 0. All I've done to the libFLAC code is add a few 
> print statements that make it clear where the failure is happening. 
> The file 'fails.flac' demonstrates the issue. The file 'succeeds.flac' 
> is in the same format but can seek successfully to 0.
>
> I'm running Xcode 8.1 on OS X 10.11.6. We have also seen this issue on 
> iOS.
>
> Please let me know if you need any further information (or if anything 
> is wrong with this example), and thanks again!
>
> On Mon, Nov 21, 2016 at 3:25 PM, Luke Bradford <lbradford at izotope.com 
> <mailto:lbradford at izotope.com>> wrote:
>
>     Hi,
>
>     Thank you both for your replies. I will try to put together a
>     repro case when I get a chance.
>
>     In our case, we are recording audio directly into FLAC files, so
>     they can end up with very short durations. Since I sent my first
>     email, I have also seen this reproduce with longer files.
>
>     Thanks,
>
>     Luke
>
>     On Mon, Nov 21, 2016 at 3:07 PM, Federico Miyara
>     <fmiyara at fceia.unr.edu.ar <mailto:fmiyara at fceia.unr.edu.ar>> wrote:
>
>
>         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
>
>
>         _______________________________________________
>         flac-dev mailing list
>         flac-dev at xiph.org <mailto:flac-dev at xiph.org>
>         http://lists.xiph.org/mailman/listinfo/flac-dev
>         <http://lists.xiph.org/mailman/listinfo/flac-dev>
>
>
>
>
>     -- 
>     Luke Bradford
>     Senior Software Engineer
>     luke at izotope.com <mailto:luke at izotope.com>
>
>     iZotope, Inc.
>     www.izotope.com <http://www.izotope.com>
>
>
>
>
> -- 
> Luke Bradford
> Senior Software Engineer
> luke at izotope.com <mailto:luke at izotope.com>
>
> iZotope, Inc.
> www.izotope.com <http://www.izotope.com>
>
>
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev